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

List:       koffice
Subject:    Re: QDomDocument for each app
From:       Erik Severinghaus <ErikSev () intrex ! net>
Date:       2000-02-25 1:44:09
[Download RAW message or body]

David Faure wrote:
> 
> On Thu, Feb 24, 2000 at 08:22:07PM -0500, Erik Severinghaus wrote:
> > Matthias Elter wrote:
> > >
> > > Michael Koch wrote:
> > > >
> > > > Am Thu, 24 Feb 2000 schrieb Erik Severinghaus:
> > > > > Let me preface by saying that I am new to QDom stuff, and couldn't find
> > > > > any documentation online in the qk section. That being said, wouldn't it
> > > > > be wiser to move the main QDomDocument for the apps from the specific
> > > > > apps to KoDocument, that way we can create one generic app for the
> > > > > properties which apply to all (essentially the stuff implemented in
> > > > > KoDocumentInfo)? Or am I missing something.
> > > >
> > > > Good idea but not all all apps want to use QDOM, e.g KWord uses KOML.
> > > > Perhaps this wil change in KWord 2.0
> >
> > Yeah, I had been using kimage for testing, and hadn't noticed that
> > KWord, KPresenter, and others are using KOML. Are we waiting till 2.0 to
> > port kword et al to qdom?
> I guess.
> 
> > It seems like a bad idea to implement the
> > KoDocumentInfo for both KOML and QDom.
> ... although it might not be very difficult...
> 
> > I can help with the porting of
> > stuff, but am not too terribly experienced, and have 0 experience with
> > KOML and QDom. Plus I don't have more than a couple hours a day to
> > devote to hacking. :( I guess my question is, what's the roadmap? How
> > dificult would the port be? Is it worth it?
> 
> Torben's ("God") input on the question was that it's going to
> be quite difficult to port, e.g. KWord, because of the way it uses
> KOML. I can't remember the exact reason though.
> 
> If I were you, I would let the porting to the author, Reggie,
> unless he can state his opinion on the subject (but I know he's very busy...)

Sounds good to me. I figured it'd be tough or it'd be done by now. :)
 
> Implementing KoDocumentInfo for both (or perhaps so that it returns a QDom
> document and the app write it back using KOML ?) is certainly easier.

Ok. Is it a good idea to move the QDom stuff to the kodocument class?

Erik

> Sorry that the news don't look so good... KOML is there for historical
> reasons, we need to get rid of it, but it doesn't seem to be easy.
> 
> Disclaimer: all this is only from what I heard and can recall, not from
> first hand knowledge. Feel free to prove me wrong.
> 
> --
> 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]