kdom and khtml integration

[Maks Orlovich]

On Sunday 05 March 2006 16:16, Nikolas Zimmermann wrote:
> Hi Andras,
>
> > A little. In short, we want to have in Quanta a common DOM tree for
> > source and VPL (WYSIWYG) mode. Right now we have our own tree and there
> > is the KHTML DOM tree. This requires intensive synchronization between
> > the two whenever the document is modified in source or VPL mode. With
> > KDOM we wanted to solve this problem, and can you tell me if this will be
> > possible?
> >
> > What I was thinking is:
> > - parse the document with our own parser and create a KDOM based tree
>
> Hm, you probably need to parse additional stuff like PHP etc? Can you
> elaborate a bit more, how you reuse khtml's parsing/tokenizing in Quanta?
> (do you use it at all? or do you build two completely seperated trees)
>
> > - the KDOM tree nodes must be extensible (they should be able to hold
> > extra information)
>
> That will definately be possible, just like the NodeImpl contains pointers
> to the RenderObject, we can also supply nodes with "UserData".

That's not trivial. Adding pointers to NodeImpl will introduce considerable 
bloat and is not to be taken lightly. We could probably abuse the 
ListenerList pointer somehow, though, by making it a chain of optional stuff 
or such. Would take some thinking to get the abstraction right, but seems 
doable.

Inheritting off internal types is of course simply -impossible- if we want 
freedom to change them.

>
> > - KHTML should be able to render directly this KDOM tree (for VPL mode)
>
> If you want _one_ tree, then you need to let the html parsing/tokenizing
> create the tree. A custom parser can't help there?

Well, I guess it may be nice if one could magically animate for 
rendering/attach a custom-built tree. Not sure how hard it is to wire, and I 
guess you probably know more about all the evil roundtrips via part/view than 
me.