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

List:       kde-core-devel
Subject:    Re: kparts
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-11-01 13:31:06
[Download RAW message or body]

Hi,

On Mon, 1 Nov 1999, Simon Hausmann wrote:

> 
> 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? :-)

The real truth of canossa is that my notebook was too slow for mico
development and I wanted to port KSpread to pure Qt. That is why canossa
did not contain a line of KDE code in the beginning.

It was not really designed with konqui in mind. I thought about konqui
only after I realized how neat it is compared with CORBA.

The document view thing is a very hard constraint for many apps.
For KOffice very nice and useful but in general it s a complex task.
Most non koffice apps will not use document/view at all usually.

That means one can ot embed konqui directly in KSpread, which is ok :-)
But the other way should work: Embed a KSpread in Konqui.

In KLibFactory the 3rd argument is a classname. If a Koffice components
is asked for "Part" then it returns the document class that can handle
the document/view model. If the 3rd parameter is "SimonsWidgetEmbed"
then it should return an object that is derived from QWidget and hosts
a KSpreadView. This way you can embed Koffice components everywhere.

The remaining problem is: How to handle GUI merging. The approach of
koffice is a hard constraint, too, sice konqui shows that non koffice
apps do other kind of merging. But nevertheless the basic thing is
the same: The embedded component offers QActions in a QActionCollection
which are somehow used by the embedding program.

Readonly/ReadWrite:
IMHO this has nothing todo with document/view or single-view.
You may still want to embed a single-view text-editor which is
of course not readonly.

So I suggest the following:

- Move the QPainter, rotated, scaled, document/view approach to Koffice
  and out if libkparts.
- Provide a KEmbedWidget or something like this. That is the
  "SimonsWidgetEmbed" I mentioned above :-)
- class KReadOnlyEmbedWidget : public KEmbedWidget
- class KReadWriteEmbedWidget : public KReadOnlyEmbedWidget
- class KOfficeEmbedWidget : public KReadWriteEmbedWidget
- Use kioslave to allow for network transparent access.

Of course the Shell concept has to die at the same time. The basic task
of the shell is to keep track of what is active
and to make GUI merging.

In KOffice it is a bit more complicated. You can select components
while another is still active. The embedding in KOffice is a tree
structure. The "SimonsEmbedding" has no tree structure: It is flat.
That means: If konqui embeds a "VeryComplexView" then konqui
does not care wether there is a "KSpreadView" inside the
"VeryComplexView". Konqui wont care -> flat.
In KOffice it is of interest wether the embedded KWordView embeds
a KSpreadView, since we will do GUI merging for the KSpreadView, too
-> tree.

So the shell solution is easy: Move the shell to KOffice.
"SimonsEmbed" does not need a shell. It just needs an embed manager
like this:

class KEmbedManager : publi QEvent
{
   addWidget( KEmbedWidget* );
   removeWidget(...)

signals:
   activeWidgetChanged( KEmbedWidget* )
};

The sourrounding app will then just do a app specific gui merging
upon "activeWidgetChanged".

When your stuff is finished, then I will change koffice, to use a non
shell based approach, too.

The basic "shell" point is: The shell-replacement for konqui works
completey different compared with the koffice shell-replacement.

Bye
Torben


 
> 
> Ciao,
>  Simon
> 
> 

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