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

List:       kde-core-devel
Subject:    Re: [Fwd: kparts]
From:       David Faure <faure () kde ! org>
Date:       1999-11-02 22:45:17
[Download RAW message or body]

[...]
> > > 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 ?
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, ...

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


-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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