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

List:       koffice
Subject:    RE: KOffice loading and saving progress info
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-03-08 12:33:45
[Download RAW message or body]



On Wed, 8 Mar 2000, David Faure wrote:

> > On Wed, 8 Mar 2000, David Faure wrote:
> > 
> > > Hi there,
> > > 
> > > I spend some time yesterday trying to make the window
> > > for KOffice apps appear as soon as possible, so that you see
> > > something while it's loading the initial document.
> > > This approach turned out to be wrong, since the design is 
> > > currently very much document-oriented: you can't create views on
> > > empty documents (I mean - really empty, like NO tables in kspread,
> > > or NO initial paragraph in KWord). You need a basic document
> > > before you can do anything with it, which makes sense.
> > 
> > I agree.
> > 
> > This also points out a design problem we have..
> > 
> > For KParts we *require* parts to be able to "have" a view of 
> > the document, even if it is empty. It seems though, that this is difficult
> 
> > for KOffice (see the createEmptyDocument hacks in kword_factory/kword_doc,
> > for example).
> Yup, I've seen it. But... I'm not sure how related it is, nor what
> exactly it is about.
> 
> It seems to me that we require BOTH a document and a view (when
> trying to display a shell, which is what I wanted to do).

Yes, that's exactly the problem, in the display-a-shell case as well as
when embedding a koffice part in any other non-koffice, kparts aware
app/container (like in khtml_part for example).

> initEmpty() (that's its real name) provides an empty document,
> so that you can build a view on it, right ? But it seems you needed
> that for embedding into konqueror, not sure why.

It's not necessarily konqueror specific, it's just that it is impossible
to create a kword view without initialized/empty document data (as you
already found out, too) . This however is a general requirement of the
KParts design though.. (and that's what I meant with design problem :-)

> It we keep the document centric approach, it makes sense that you
> need a document before you can do anything. But we should, IMHO,
> support _really empty_ documents (as in: new KWordDocument and
> no initDoc nor initEmpty).
>
> This would allow to show a KWordShell very soon, _even with no view_ 
> inside. Then load the document, then show the view.

Hmmmm, perhaps we can use your idea also in the above mentioned parts
embedding problem? Like: creating a dummy widget *duck* :-) , create the
document, load the data and then create the real view, replacing the dummy
widget.

Hacky? Too much overhead? :-)
(probably...)

> > I could either think of
> > 
> >  a) get rid of the "fact" that parts create their view/widget in the
> >     constructor and add a koffice-like createWidget()/createView() 
> >     method/solution. This probably looks like overhead and 
> >     complexity for a simple single-view-document part
> Why can't we put that in kofficecore instead of kparts ?

Hm? createView() is already part of libkofficecore? Or am I mixing up
things?

> Yeah, in fact it seems the problem I had comes from the fact that
> createShell calls createView... If I could create a shell with no view
> that would solve the problem (and I could put progress info into
> the shell's status bar!)
> 
> >  b) try to get make koffice parts work with this constraint
> i.e. create a view on top of a 'really empty' document ?
> I've tried, believe me ;-)
> This goes too much into KWord's internals.

I believe you :-))


Hmmm, and I fear we cannot use the createWidget() approach in kparts
either, because it would only work if we'd use something like this:

part = factory->createPart
part->openURL()
part->createWidget( parentWidget );

That however sounds like broken design IMHO, as we'd require the *first*
openURL call to be placed before the widget creation. That makes sense in
the koffice document-centric world, but not in kparts, where multiple
openURL calls may follow each other (which is something most koffice apps
do not support, yet, it seems -- loading a new document is always like:
delete currentDoc; doc = new Doc; doc->load() ; --- in contrary to the ROP
way of currentDoc->openURL() ; user wants to open another doc; currentDoc->openURL() ;

So are we really left with the dummy widget solution?

Bye,
 Simon

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