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

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

Hi,

On Wed, 3 Nov 1999, Simon Hausmann wrote:

> 
> 
> On Tue, 2 Nov 1999, David Faure wrote:
> 
> > [...]
> > > > > 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.
> > 
> > Those are only "widgets". If we want ReadWrite functionality, we probably
> > need more than widgets. One doesn't say "is this widget modified", right ?
> > It doesn't make sense...
> > 
> > I agree that document/view is too complex for simple apps
> > (I keep thinking of kwrite as a very good candidate for this ReadWrite embedded
> > thing, since kdevelop needs it).
> > 
> > Perhaps talking about "parts" would be more appropriate ?
> 
> Yes, I'd like that! :) Let's choose the term kparts (IMHO)
> 
> > Although the current Part concept in kparts is somewhat different...
> > 
> > I'm not only talking about naming, of course, but about functionality.
> > We need to load, save, know if modified, ...
> 
> ..yes, even more a reason to choose something like part, IMHO.
> 
> > > > 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.
> > 
> > All this is fine to me.
> > 
> > > 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.
> > 
> > Yes, exactly. Well it might just be a naming problem then :)
> > This is much more than a "widget"...
> > 
> > Oh I found it : a Component. (Hi Stephan !)
> > 
> > The KDE Component technology would have
> > ReadOnly Components (like kdvi, kghostview, ...)
> > ReadWrite Components, like kwrite, 
> > and of course koffice component which inherit from ReadWrite Component.
> > (or is that the actual "KOffice View" ? probably)
> 
> Hmmm, I'm not quite sure about calling it "component", but.. who cares ;)
> (/me not ;)

In KDE components are historically called "parts" :-)

KOfficeView would NOT be derived from the ReadWrite Component interface.

A KOfficeWrapper would be and that wrapper in return owns a KoDocument
and a KoView then.

I think most of the code in "Part" has to move to KoDocument and
lots of the "View" and "ContainerView" has to go to a new class KoView.

I think one thing was not explained clear enough by me:
KOffice will "internally"! not use the new embedding stuff. It will
use KLibLoader and KLibfactory and such but NOT the ReadWrite Component
stuff. There will just be a class KOfficeWrapper which makes Koffice
components appear like usual KDE components.

Bye
Torben

BTW: Why not deriving KDE Component from QWidget? Where is the problem
with it having a save method? IMHO no need to invent a new class just
to have no save method on a QWidget derived class.

> Bye,
>  Simon
> 
> 

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