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

List:       kde-commits
Subject:    Re: kdeutils/knotes/qt3stuff
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-09-26 10:15:54
[Download RAW message or body]

On Mercredi 26 Septembre 2001 12:12, Martijn Klingens wrote:
> On Wednesday 26 September 2001 11:49, Malte Starostik wrote:
> > I'm not sure how gracefully KHTML will handle a long session with a high
> > history limit...e.g. how much memory will it eat when there are 10000 lines
> > of text? But the idea about adding DOM nodes sounds good, didn't think
> > about that before and I was afraid KHTMl wouldn't like addint single lines
> > of text all the time without actually closing the document node.
> > But (/me hasn't got too much of an idea about KHTML & DOM), is it possible
> > to modify the DOM tree with just KHTML's public headers, or do we get the
> > same situation there - except it's a private KDE header and not a private
> > Qt header :)
> 
> Probably you won't encounter problems, since Simon traverses the DOM tree in 
> KBugBuster. I don't think he needed private headers there ;-)
> 
> Besides, Konq plugins need access as well, and of a whole lot of other 
> related methods I am sure they are documented as public API.
> 
> So, no, I don't think you'll hit problems regarding private API.

Yes, DOM is public.

> Regarding performance: I don't know, it would be a nice stress-test to see 
> where KHTML needs profiling :-)

I think it's a bit crazy to use KHTML for ksirc....
(and I would vote for most QRichText classes being public, too).

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/ , http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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