kdom and khtml integration

[Leo Savernik]

Am Montag, 27. Februar 2006 00:21 schrieb Rob Buis:
> Good evening khtml hackers :-)
>
> As some of you may know we have been working the last
> year(s) on kdom/ksvg2/kcanvas - three seperated projects. The initial
> aim was to decouple the whole DOM from the HTML stuff, which is contrary
> compared to khtml itself. We've now reached a state where we actually need
> integration of at least ksvg & khtml to support fancy things like CDF
> (ie. xhtml in svg or the other way round). WebKit+SVG has already done
> that by creating SVG RenderObjects and coupling the projects.
>
> We haven't been convinced of this coupling so far, hence we introduced
> a lot of things (CDFInterface, EcmaInterface, etc..) in the ecma & css
> areas to be able to make kdom a "base" for ksvg and khtml which results in
> a lot of 'virtual' usage, and more other things (don't want to describe all
> in detail) which makes it impossible that our stuff will ever be as fast as
> an integrated environment.

Summarized, Apple went for the monolithic approach while you went for the 
componentized.
>
> In addition to the speed problem, a protype has shown that seperating
> kdom from khtml+ksvg gives problems with the design of things like
> css and rendering. For instance, would kdom need a css parser? 

Do khtml2 and ksvg2 still do their css parsing separately? If yes, I see a big 
potential for factorisation. Given that style information is represented by 
DOM, too, I can't see any contradiction in providing uniform interfaces for 
style parser backend within kdom.

> If so, 
> what css properties should it support? 

Bluntly, all of them.

> Even besides that, kdom's NodeImpl 
> would need to have rendering "hooks", that would need to be implemented
> by the layers on top. It would be awkward to have to add new rendering
> hooks later on.
>
> Hence we think for the future it makes more sense to go the "integrated"
> way, aka. kdom & ksvg & khtml all in one library. As khtml is de-facto
> way more tested then our stuff we think that it's a good time now to merge
> the "good things from kdom" into khtml trunk, while ensuring no regressions
> are being introduced (of course :-). 

First of all, I agree with your way of thinking. Building upon your ideas, I 
suggest a two-pronged approach featuring a balanced compromise between 
efficiency and extensibility:
1. Document types which fully integrate within kdom (like html+svg+mathml+...) 
should be compiled into one monolithic block with full access to internal 
information.
2. Other document types being less demanding should be allowed to participate 
in the rendering and layouting process insofar to provide them with true 
stacking order and true transparency. I call them "lightweight" KParts. They 
don't have a QWidget of they own, but get granted a rectangular area from 
their container to paint into, and are laid out along with all other 
containers children.
(3. There's a third type that directly works on the dom and doesn't need any 
visualisation device like xpath, xslt whatever. Those could be realised as 
"real" components as well as compiled in by default, but still sticking to 
public api only.)

Approach (1) resembles the Linux Kernel development way of life: There *are* 
interfaces to write code against. Those interfaces are *not* guaranteed to be 
stable. By linking it together, an efficient yet architecturally clean binary 
can be achieved.
Approach (2) resembles componentisation. For it it is imperative to provide a 
stable api for the lifetime of KDE 4. Hence, to keep this promise, we must 
not make available more information than we're confident about that it stays 
stable (like the minmax-calculation, the layout pass and the painting 
pass(es)).

> The next step would be merging 
> ksvg(2) into khtml, and renaming khtml to sth. like "kxml".

Hmm, kxml sounds, hmm, too, er, underrating. When I read kxml, I thought about 
an xml-parser. At least if I read "xml", I associate it with a plain file 
with a multitude of xml-tags encoding some information. However, I associate 
"html" with a full-fletched *browsing experience*, not a bland file 
containing markup.

Maybe I'm poisoned by heavy usage of khtml ;-), but I feel it has become a 
brand throughout KDE I actually don't want to have sacrifised easily.

>
[...]
> Here is an unordered list of the "good things from kdom":
> * One-Class-One-File policy aka. having kxml/core/NodeImpl.cpp AttrImpl.cpp
> etc..
Matter of taste. Most apparent disadvantage: Takes much longer to compile.
As far as the other points are concerned: I fully agree.
>
[...]
> Please note that Webkit+SVG clearly shows that integrating svg with (x)html
> can be done. Also our prototype, which groups ksvg2 and khtml2 and makes
> use of SVG render objects in the same way as in Webkit, can handle
> xhtml+svg fine, see for instance
> http://www.xs4all.nl/~rwlbuis/simpleCDF2.png

How about the state of compatibility between kdom/khtml2/ksvg2 and WebCore? 
The less differences the easier it is to merge stuff.
>
> So, here is our proposal:
[...]
>
> Finally note that we are here proposing a possible process of integrating
> more tightly in order to improve xml technologies support of Konqueror. We
> are open to suggestions on how to go about doing this :)

Not being the maintainer of khtml, I can't decide whether this process is 
viable. However, we're on a junction with 3 roads to go:
1. staying with old khtml
2. integrating kdom+khtml2+ksvg2 into old khtml as proposed by you
3. dumping khtml and use WebCore

As (2) or (3) are likely to prevail over (1), extensive compatibility between 
(2) and (3) will make it easier for KDE to remain independent from WebCore, 
yet still take advantage of it.
>
> Rob Buis <buis at kde.org>
> Nikolas Zimmermann <wildfox at kde.org>

mfg
	Leo