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

List:       kde-commits
Subject:    Re: kdeutils/knotes/qt3stuff
From:       Reginald Stadlbauer <reggie () trolltech ! com>
Date:       2001-09-26 10:29:43
[Download RAW message or body]

On Wednesday 26 September 2001 12:15, David Faure wrote:
> 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).

Well, the reason why I didn't make them public yet is:

- not everything we want to implement is implemented yet and we don't want to 
limit our possibilities because of publishing an API which we might need to 
change a bit
- The API is not polished enough to meet the standards of normal Qt API
- No documentation written yet

-- 
Reggie (reggie@trolltech.com)

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