kdom and khtml integration

[Nikolas Zimmermann]

Heya,

> > * One-Class-One-File policy aka. having kxml/core/NodeImpl.cpp
> > AttrImpl.cpp etc..
>
> I would actually consider this to be a Very Bad Thing.
>
> Amongst disadvantages:
> - Longer compile times
>
> - Much harder to work on related areas of code: while right now one can
> open 2-6 files and be done, this would potentially involve opening 30+.
> Also consider e.g. working on attribute handling. That generally involves
> touching AttrImpl, AttributeImpl, NamedAttrMap, ElementImpl, etc. These are
> now all nicely in the same file, so one can get a decent overview without
> scooting around. Not to mention do you really think classes whose
> implementation is this long: ChildNodeListImpl::ChildNodeListImpl( NodeImpl
> *n ): NodeListImpl(n, CHILD_NODES) {}
>
> bool ChildNodeListImpl::nodeMatches( NodeImpl* /*testNode*/, bool&
> doRecurse ) const {
>     doRecurse = false;
>     return true;
> }
>
> deserve separate files?

Nah the rules aren't meant to be _that_ strict, for instance NodeImpl & 
NodeBaseImpl should live in one file, just like NodeListImpl &
ChildNodeListImpl. (maybe that "policy" was phrased too strict...)

It just seems easier for me go through 5 smaller files, then one big one.
As Leo stated pretty nicely: It's a matter of taste. I wouldn't go mad if
you guys wouldn't like that scheme - still I think it would be nice to have.
Anyway the khtml-core-ppl should decided such things.

[...]
> > * Multiple parsing backends (ie. libxml2)
>
> We need just one that works well, and hopefully wouldn't link to multiple
> XML libraries at once.
There's no linking involved at all (at least not in libkhtml.la). The parsing
backends are KDOM::Parser objects dynamically loaded via KTrader/KLibLoader.
Currently there are libxml2 & qxml parsing backends.

[...]
> > So, here is our proposal:
> > 1. Split up to more files, like kdom/ksvg & WebCore does,
> >    for example dom_nodeimpl.h -> NodeImpl.h.
>
> See above.
>
> > 2. Consider merging webkit datastructures like AtomicString/QualifiedName
> > and ElementFactory. This is optional ofcourse, however we have good
> > experiences with this functionality in kdom.
>
> I would really appreciate if someone explained what they're actually -good-
> for. (QName particularly) What I see most is that e.g. QualifiedName really
> uglifies the places where we have switches. And while I am not really happy
> with the name -> ID mapping code currently, that's no reason to throw out
> the integer-ID concept.
(Answer comes later - )

>
> > 3. Merge in "best of kdom"
>
> It would be nice of you elaborated on the cool stuff you have there. Or is
> the list below supposed to be there?
Well I actually planned to delay that until I actually plan to port XYZ into 
khtml. Say I'd like to port the 'XInclude' stuff to khtml, then I'd first
elaborate on it, tell about it pros & cons, the benefits etc..
(I wanted to make it possible to start the 'easy stuff' at some point,
 w/o dying in detailed discussions about stuff I don't care for atm..)

> > 4. Merge in ksvg2 code.
> > 5. Merge in a subset of kcanvas into khtml/rendering.
> > 6. Nice to have: do autogeneration of cpp/js bindings?
Good to see we agree on the most important points :-)

>
> > 7. Consider renaming khtml to kxml, to reflect the improved xml
> > capabilities.
>
> To me, that name would suggest it's a mere XML library.
Ok other suggestions: libsaverniK, libmaKs, libdirK, libniKo? ;-)
So we should better stick to 'khtml' - as it's a "well-known" brand
throughout KDE? Or does anyone still think a rename would be cool?

>
> Good luck,
> Maks

P.S. It would be nice if Germain & Dirk could also comment...