From kfm-devel  Mon Jan 16 16:51:06 2006
From: Koos Vriezen <koos.vriezen () xs4all ! nl>
Date: Mon, 16 Jan 2006 16:51:06 +0000
To: kfm-devel
Subject: Re: KHTML, KJS Unfrozen -- details
Message-Id: <20060116165105.GA7324 () xs4all ! nl>
X-MARC-Message: https://marc.info/?l=kfm-devel&m=113743027223624

On Sun, Jan 15, 2006 at 06:05:06PM -0500, Maks Orlovich wrote:
> > Seriously, since I've added KJS CPU guard, what will be the replacement?
> > Also, what happens with the js <-> plugin interface, will that remain or
> 
> It will remain if someone fixes it, or explains to me how it works, unless of 
> course you dislike it ;-) 

Like said, I posted an alternative (thread Patch: Using kpart's
KJS::Interpreter (was Re: XML, XSL, XSLT, XPath support?)), which is a
much more powerfull solution.
Unfortunately, there wasn't much comment on this path. Eg. I don't know,
how easy it is to create an js interface on the fly (think of java and
nsplugin). Ie. does that mean with kjs-embedded, that signals/slots
should be added in runtime? Can this be done with bare kjs (I think so,
but the usecases in ecma all have static tables)? And of course in that
case, do we want plugins to link against kjs (and not kjs-embedded, what
I read was that the policy is in kde4 to link against kjs-embedded.)
Anyhow, what do you think?

Koos