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

List:       kde-core-devel
Subject:    [Fwd: kparts]
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-11-02 20:18:32
[Download RAW message or body]

-- 
Everyone makes mistakes -- but we are more experienced at it
                                      anonymous KDE developer

Received: from master.kde.org
	by localhost with IMAP (fetchmail-5.1.2)
	for coolo@localhost (single-drop); Tue, 02 Nov 1999 23:11:52 +0100 (CET)
Received: from wotan.itm.mu-luebeck.de ([141.83.21.121]:29084 "EHLO
        itm.mu-luebeck.de") by max.tat.physik.uni-tuebingen.de with ESMTP
	id <S743071AbPKBUCq>; Tue, 2 Nov 1999 21:02:46 +0100
Received: from max.tat.physik.uni-tuebingen.de (max.tat.physik.uni-tuebingen.de [134.2.170.93])
	by itm.mu-luebeck.de (8.9.1/8.9.1) with ESMTP id VAA12315
	for <coolo@itm.mu-luebeck.de>; Tue, 2 Nov 1999 21:02:45 +0100 (MET)
Received: by max.tat.physik.uni-tuebingen.de id <S743071AbPKBUCY>;
	Tue, 2 Nov 1999 21:02:24 +0100
X-From_: shaus@helios.Med.Uni-Magdeburg.DE Tue Nov  2 21:02:24 1999
Received: from a1as01-p38.bln.tli.de ([195.252.149.38]:4868 "EHLO
        neuro2.med.uni-magdeburg.de") by max.tat.physik.uni-tuebingen.de
	with ESMTP id <S743119AbPKBUCI>; Tue, 2 Nov 1999 21:02:08 +0100
Received: from localhost (shaus@localhost)
	by neuro2.med.uni-magdeburg.de (8.9.3/8.9.3) with ESMTP id WAA01833
	for <kde-core-devel@kde.org>; Tue, 2 Nov 1999 22:17:16 +0100
X-Authentication-Warning: neuro2.med.uni-magdeburg.de: shaus owned process doing -bs
Old-Date:   Tue, 2 Nov 1999 22:17:16 +0100 (CET)
From:   Simon Hausmann <shaus@helios.Med.Uni-Magdeburg.DE>
To:     kde-core-devel@kde.org
Subject: Re: kparts
In-Reply-To: <Pine.A41.4.10.9911011406040.35062-100000@trollinger-fe.rz.uni-frankfurt.de>
Message-ID: <Pine.LNX.4.10.9911022123150.16188-100000@neuro2.med.uni-magdeburg.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Diagnostic: Not on the accept list
X-Envelope-To: kde-core-devel
Date:   Tue, 2 Nov 1999 21:02:24 +0100
Return-Path: <kde-core-devel-request@master.kde.org>
X-Orcpt: rfc822;coolo@kde.org
X-Mozilla-Status2: 00000000



On Mon, 1 Nov 1999, weis wrote:

> 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.

Wow :-)

OK, I already talked with David and we will start hacking that stuff
somewhere in the dark directories of the kdenonbeta cellar ;-) , far away
from the frozen kdelibs and the upcoming KRASH :-)


So let's see if I understood your concept correctly. I will now just 
repeat what you already said. Please correct anything wrong!

a) KEmbedWidget, beside that is is a QWidget, is supposed to provide
   1) actions, via an actioncollection, just like in the current kparts
   2) XML, describing the layout of the actions

b) KEmbedManager is nothing but an event listener :) , filtering mouse
   button press events, and emitting the right signal if it detects a
   click (depending on available activation modes) on a KEmbedWidget
   (which has to be registered previously) .

   This is just like the current KParts Shell and the ViewManager in
   Konqueror work.

c) I believe that we should provide a GUI creation class, which takes care
   of building, activating and deactivating a GUI, based on the idea that
   one initially passes a KTMainWindow reference to it, and then XML and
   the corresponding QActionCollection of the KEmbedWidget which GUI is to
   be shown.
   IMHO we might also consider to add functionality to be able to provide
   a skeleton GUI (from XML/actioncollection) , just like the shell GUI in
   the current KParts.

d) We can base the KReadOnlyWidget, ... interfaces for
   accessing/reading/storing data on the idea of *only* passing URLs
   around, which again are passed to KIOJobs, in the implementation of the
   embed-widgets. This could then even be complex URLs like
   "tar://blah/#ftp://ftp.foo.com/pub" for example, which we could pass
   over to an embedded widget, telling it that it should store it's data
   inside there. The implementation then passes this URL to a KIOJob,
   and calle methods like put(), mkdir(), etc. to actually store/read
   data.


Comments? Mistakes? Misunderstandings? Flames? :-)


Ciao,
 Simon (..incredibly happy for having email access again, after one day of
        crashing mail servers...)



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