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

List:       kde-core-devel
Subject:    Re: koffice
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-02-06 15:43:44
[Download RAW message or body]



On Sat, 5 Feb 2000, David Faure wrote:

> On Sat, Feb 05, 2000 at 10:25:29PM +0100, Simon Hausmann wrote:
> > 
> > 
> > On Sat, 5 Feb 2000, David Faure wrote:
> > 
> > > On Sat, Feb 05, 2000 at 07:28:25PM +0100, Simon Hausmann wrote:
> > > > the port of KOffice to use kparts instead of koparts. What I basically did
> > > > was:
> > > Thanks for keeping a note of everything you changed !
> > > 
> > > About moving the actions from the view to the document :
> > > this seems right anyway, doesn't it ?
> > > Actions act on the document, not on its representation...
> > > Didn't know that it wasn't the case currently...
> > 
> > I was surprised either :-) (as it was like this (actions in the view) in
> > Canossa, too)
> > 
> > So the move seems to make sense, but it's going to be *really*
> > difficult/hard I guess, as it *strictly* enforces the document-view model
> > in KOffice, because all the slot implementations have to be in the
> > document (and act on it).
> 
> Yes, but it seems like the right thing to do anyway, no ?

Yes, at least partially (for some actions it doesn't make sense to put
them into the document IMHO, like "start screen presentation" in
KPresenter for example, which should affect only one view and not all,
or?)

> > However major apps like KWord or KPresenter do
> > not support multiple views for one document, yet.
> 
> Didn't know that.
> 
> > Perhaps we can "mix" the concept and have actions in the document
> > *and* in the views, so that the inplace-editing actions are in the
> > document at least?
> 
> This would make the transition easy, yes.
> We can then move the actions step by step...

Yep, ok :-)


Hrm, we really need more hackers :-) . We should ask Torben if he can
fork() once again :-)


> > > > - added check if the global application object is a KoApplication, so that
> > > >   the filter stuff is only used inside KOffice (otherwise it used
> > > >   to crash horribly ;)
> > > Hmm... A feature request from a guy in NY : being able to use a KWord
> > > part as a viewer in konqueror is cool, but it would be even better
> > > if it could filter files before showing them. This would give us
> > > a MS-Word .doc viewer for free. Why does it require a KoApp ? Isn't
> > > it rather a KoFilterManager that it requires ? In this case we need
> > > to find a way to create & provide the filtermanager even when embedding
> > > only the part... Hmm...
> > 
> > I thought of that, too. The only requirement for that is the native
> > mimetype format. But IMHO it makes sense to have that information in the
> > document anyway (it was like this in the old CORBA based KOffice, too,
> > IIRC) . I guess Werner can help here? :-)
> 
> Hrm, it's in KoApp because it needs it to get hold of the document "entry".
> (see KoApplication::start())
> A chicken and egg problem :-)
> 
> And you can't make it a static method of KoDocument, since it's not possible
> to override a static method (is it ?)...

Hrmm.. 

Perhaps I'm missing some point, but do we need the static native-mimetype
stuff in KoApp?

The static methods aren't used in KoApp::start() actually, instead the
arguments passed via the KoApp constructor are used. So the only place
where KOAPP->nativeMimeType() is called is from within
KoDocument::loadFromURL (IIRC) . However I don't see why it should't be
possible to call a method from KoDocument (itself) in there?

What do you think?

Ciao,
 Simon

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