kdom and khtml integration

[Paulo Moura Guedes]

On Monday 06 March 2006 23:28, Leo Savernik wrote:
> Am Montag, 6. März 2006 22:30 schrieb Paulo Moura Guedes:
> > > 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.
> >
> > Not sure about what you mean, but such a WYSIWYG editor would need to
> > draw custom content on the canvas.
> > AFAIK, this is internal functionality not available to external apps, as
> > expected for the purpose KHTML was designed (this is the extensions
> > points I mentioned in the other thread).
> > I would like to discuss that a little and hear KHTML developers opinion.
>
> As far as I've understood, Quanta needs two types of interfaces. First a
> means to inject a custom DOM-tree into khtml which is in turn laid out and
> rendered by it. Second, a means to get extents and style information about
> rendered objects exceeding what can be determined currently by the public
> DOM api.
>
> I'd like to know which kind of information VPL needed from the khtml
> renderer to work effectively. 

VPL needs to work like an editor and the editors today have to draw custom 
stuff on the screen that gives information or can be clicked or dragged to 
perform some action. So it's not just about showing the page content. 
An example of this can be seen with NVU or Mozilla composer (you can run it 
from the browser window) that draws a border with squares around the pictures 
so one can resize them.
I wonder how can this be possible with KHTML.

Paulo

> If the information is not too specific, it 
> should be possible to design a stable api that satisfies both khtml's need
> for internal api flexibility and efficiency, and VPL's or any other
> consumer's need to interact with the rendered content.