[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic