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

List:       kfm-devel
Subject:    Re: kdom and khtml integration
From:       Frans Englich <frans.englich () telia ! com>
Date:       2006-03-05 16:41:53
Message-ID: 200603051641.54078.frans.englich () telia ! com
[Download RAW message or body]

On Friday 03 March 2006 14:41, Maks Orlovich wrote:
> > > 2. Consider merging webkit datastructures like
> > > AtomicString/QualifiedName and ElementFactory. This is optional
> > > ofcourse, however we have good experiences with this functionality in
> > > kdom.
> >
> > Yes, I agree with that.
>
> Could you perhaps elaborate on the advantages? I am quite concerned about
> loosing all the nice switches.
>
> > > 7. Consider renaming khtml to kxml, to reflect the improved xml
> > > capabilities.
> >
> > Then we can as well go with "webkit" as a name ;)
> >
> > Honestly, I fail to see which problems you saw with the modularisation?
> > Perhaps then it would be easier to decide. Right now I don't think that
> > "avoiding a couple more virtual functions" would be a ground you base the
> > start of spaghetti code (see Safari) on.
>
> Well, one issue I talked about with Niko is that we definitely do not want
> to guarantee BC in impl classes. So if it's modular, we'll have to do some
> sort of thing where ksvg version is paired to the khtml version.

I agree that BC is problematic. But I don't see how building a monolithic 
library removes the requirement because Quanta needs the tree to be BC, for 
example.

I am close to a solution, and that's to add an interface/implementation 
separation in the DOM sense(not in the bindings sense). See "part two" of 
this mail:

http://mail.kde.org/pipermail/ksvg-devel/2006-February/000403.html


Cheers,

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