[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Swfdec/Konqi integration
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2007-06-18 23:57:08
Message-ID: 200706190157.14197.kevin.krammer () gmx ! at
[Download RAW message or body]


On Tuesday 19 June 2007, koos vriezen wrote:
> 2007/6/18, Kevin Krammer <kevin.krammer@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.

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?

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.

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

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]