KHTML, KJS Unfrozen -- details

[Maksim Orlovich]

> 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.

Will look, but not right now (exam in 1.5 hour ;-) )

> 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).

It's pretty easy if you don't need to do something funny that messes with
normal lookup order (some of the html interfaces do both)
Basically, you need to be able to check whether a property with a given
name is there in ::getOwnPropertySlot, and then return a pointer to the
getter function (which will be given parameter names again), and handle
put based on whether it's there or not.

Note: if it wasn't clear from the above, the LiveConnect stuff is broken
in the branch ATM.


> 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)?

As above, yes.

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?

I think that pmax should clarify what he meant by linking to kjs-embedded :-)