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

On Mon, Jan 16, 2006 at 12:09:39PM -0500, Maksim Orlovich wrote:
> > 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 ;-) )

That would be cool.

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

I don't follow you exactly, but if you mean that objects, having methods
and properties, not seen before, can be easily mapped into
kjs-(embedded) with introspection and all, then I'm happy :-)

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

I don't hope you mean a kde-3.x branch though ..

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

From what I remember, it had something to do with BC (which makes sense
for plugins that don't live in kdelibs/kdebase)

Koos