XML, XSL, XSLT, XPath support?

[Koos Vriezen]

On Fri, Apr 08, 2005 at 06:11:05PM +0200, Leo Savernik wrote:
> Am Freitag, 8. April 2005 09:29 schrieb Koos Vriezen:
> > Compound Document Format sounds cool. But do you expect everything to be
> > KDOM based (and isn't that a lot of work, or is it realistic)? 
> 
> No. It's mostly about KDOM based documents being able to embed other KDOM 
> based documents or generic kparts, and forwarding to them the appropriate 
> events.
> 
> > Now we have 
> > only kpart based embedding, which has the obviously benefits of re-using
> > work of others.
> 
> Even ordinary kparts would profit from integrating them more tightly into the 
> layout+render process, be it only for proper z-stacking.

Can be quite difficult if a javascript menu should draw itself over a
plugin. Needs atleast an extra widget wherein khtml render also paints
that is positioned over the plugin's widget. Remember that most used
plugins are java applets, flash or video. Can't just pass a QPainter ..
OT, I'm thinking about this quite some time already because the SMIL in
kmplayer needs something like this too.

> > However, when it comes to cross document scripting, we only have
> > liveconnect now. I recall asking Rob once if kparts using libkjs could
> > be connected in khtml. Does someone reading this knows, can libkjs
> > iterate over its global objects and can a kpart-host use that one? That
> > would solve it too, ie. connect a kparts global to khtml's OBJECT and
> > push some 'top' global in the kparts scope. 
> 
> That'd be way cool.

Lets wait if David/Harry think it's possible. I can already implement
it, because it can work w/ current liveconnect. Just check for a
liveconnect extension first and if that fails try the kjs global thingy
or vica versa.

> > Allthough one would be at 
> > the grace of the kpart writer whether the ecma binding would be DOM (but
> > does that really matter for eg. a PDF viewer).
> 
> This doesn't really pose a problem. Now that kate is getting scripting 
> support, I'd love to see it being scriptable as an embedded object, too.
> (In kate's case, they could even simulate a simple dom tree:
> Document
> + HTMLElement
>   + HTMLHead
>   + HTMLBody
>     + TextNode (containing whole document).
> )

Exactly, and I've read about pdf has javascript too these days. But it
doesn't has to be DOM-like, take fi. the java plugin where javascript
can see the whole applet and owning objects/functions. Although some
kind of weak references must be in place for eg.
  var i = myobj.myotherobj;
  i.myfunc(); // myobj.myotherobj might be deleted by now


Koos