[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    kparts
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-11-01 12:35:33
[Download RAW message or body]


Yesterday I had a very interesting discussion with David on IRC :-)

We discussed about kparts, embedding and all that stuff.


Currently we have two kinds of embedding in KDE:

1) KOffice embedding

  This is realized by using KParts and it is a read-write embedding, based
  on the document/view model, making it possible to view and modify URL
  referenced documents.

2) Konqueror embedding
 
  The embedding of views in Konqueror has nothing to do with KParts, it
  doesn't even use this technology. It's solely based on the BrowserView
  interface (see kdelibs/interface/browser.h) , is designed for Konqueror
  and is a read-only embedding, which means it provides an interface to
  only browse/view data, referenced by an URL, without actually modifying
  it. It is not based on the document-view model.


Our concern is that with these two kinds of embedding it is impossible to
have that often mentioned "general" embedding, like for example embedding
kwrite into kdevelop as editor component.

The KOffice technology is too specialized/complex (and it's simply part of
the koffice project), and the Konqueror embedding is not general enough,
is a read-only thing and does not provide that kind of GUI merging like
kparts provides.

The point about why kparts, in its current state, is not suitable for the
above mentioned example, is

 a) it does not provide any methods to reference, access, open, modify
    data.

 b) it's too koffice specific.
    This is because it contains things like non-recangular embedding
    (rotating, stretching, shearing, etc.) and additionally requires
    documents (parts) to provide a QPainter based drawing support.

    While these features are oustandingly impressive, they are quite only
    useful for koffice (or in other words: add unnecessary complexity for 
    "normal" kde applications :)

So we discussed about implementing the following:

Move some features from kparts to libkoffice* and create a new set of
interfaces, on top of kparts: A document-view oriented (like
kparts itself) set of interfaces, providing methods for read-write access
to URL referenced documents and for a simple QWidget based graphical
embedding. In addition we might need interfaces to actually read/store
data, like the koffice store. We might perhaps consider using the kioslave
technology for that.


What do you think of that? :-)


Ciao,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]