Swfdec/Konqi integration

[koos vriezen]

2007/6/19, Kevin Krammer <kevin.krammer at gmx.at>:
> On Tuesday 19 June 2007, koos vriezen wrote:
> > 2007/6/18, Kevin Krammer <kevin.krammer at gmx.at>:
>
> > I'm not sure what you're after.
>
> Yes, sorry, I don't know either the old nor the new plugin spec, so I am
> mostly guessing :)
>
> > In kde3 it's a mimetype setting. So if one installs the beta flash
> > plugin, one should select a kpart that supports this.
> > Alternatively if one kpart, eg nsplugin support multiple runners, it
> > has to scan the plugins anyhow for the mimetypes and plugin
> > description, so I can probably find the required toolkit as well.
> > Brute force is to use 'nm' :-) and look for symbols.
>
> I imagine a workflow like this:
> 1) browser sees that it needs a plugin for an embedded content of a certain
> MIME type
> 2) browser checks which plugin offers support for that MIME type
> 3) browser checks if plugin needs XEmbed
>
> and now, my guess:
> 4) browser has to ask the plugin, or look into its stored information (plugin
> meta data?), what toolkit requirements the plugin has so it can launch the
> correct plugin runner and tell it to load the plugin.
>
> Perhaps the plugin information, which in the case of Konqueror is gathered by
> nspluginscan (correct me if I am wrong), does already contain the necessary
> information.

AFAIK nspluginscan collects the mimetypes and plugin descriptions from
the ns plugins. I guess it also checks whether it supports the plugin
(eg. I can't recall seeing the javaplugin appear in the list), but
I;'m totally not sure ..  But since for getting this info one must
load the plugin, so getting the other info is possible I would say.


> However, from Maksim's answer, I take it that this is currently not covered,
> so it would have to be added to any new specification as well.
>
> > > What's the difference of manipulating js objects and evaluating scripts?
> >
> > The problem is that js objects need to be stored somewhere for the
> > livetime of the NPObject's. I've now assigned these to variables of
> > the embed DOM object. But that is of course a hack, as it exposes
> > internal stuff to the javascript of the container page.
>
> Hmm, ok. NPObjects are on the side of the plugin, i.e. data structure within
> the plugin runner's address space? In the case of in-process plugins, where
> does the browser store their counterparts?

It's probably a direct reference to the js object. Unfortunately
kparts can't do that. Some long time ago I proposed[1] an addition to
kparts, so kparts could pass their kjs interpreter to each other. We
really need something like that to implement this or else all we have
'evaluate'.
Alternatively, we should give up using kparts for this and implement
this directly in the khtml.


> From the D-Bus point of view it would be easy to have a call runner->browser
> where the browser creates a local object and returns that object's D-Bus path
> and the runner would then create a proxy for it and map its NSObject onto it.

NPObject's are meant to be sub-classed, so add the dbus object path
directly in the NPObject.

> > runner exposing objects, yes. Javascript can call methods on the
> > plugin to eg. jump to a certain frame. Googled for this for flash
> > found
> > http://www.adobe.com/support/flash/publishexport/scriptingwithflash/scripti
> >ngwithflash_03.html to give an idea. Note neither nsplugin nor this version
> > does not support this.
>
> Ok, would be just like the above case, just the other way around.
>
> > There was also something with deadlocks IIRC that one shouldn't wait
> > for return values. I remember solving one case w/ DCOP where two calls
> > where made from two processes to each other at about the same time and
> > both waiting for each other to reply.
> > This is no ordinary client/server conversation.
>
> Right!

I guess as long a only one side uses sync calls, that's ok (in this
case the runner)

> Cheers,
> Kevin

[1] http://lists.kde.org/?t=111305207100003&r=1&w=2