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

List:       kde-core-devel
Subject:    Re: [Fwd: kparts]
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       1999-11-03 21:39:17
[Download RAW message or body]



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 ;)

Bye,
 Simon

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