From kfm-devel  Mon Jun 18 23:57:08 2007
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Mon, 18 Jun 2007 23:57:08 +0000
To: kfm-devel
Subject: Re: Swfdec/Konqi integration
Message-Id: <200706190157.14197.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kfm-devel&m=118221117000831
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1890320.qNNyVx8cQd"

--nextPart1890320.qNNyVx8cQd
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
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=
=20
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 (plug=
in=20
meta data?), what toolkit requirements the plugin has so it can launch the=
=20
correct plugin runner and tell it to load the plugin.

Perhaps the plugin information, which in the case of Konqueror is gathered =
by=20
nspluginscan (correct me if I am wrong), does already contain the necessary=
=20
information.

However, from Maksim's answer, I take it that this is currently not covered=
,=20
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 withi=
n=20
the plugin runner's address space? In the case of in-process plugins, where=
=20
does the browser store their counterparts?

=46rom the D-Bus point of view it would be easy to have a call runner->brow=
ser=20
where the browser creates a local object and returns that object's D-Bus pa=
th=20
and the runner would then create a proxy for it and map its NSObject onto i=
t.

> 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/scrip=
ti
>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

=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart1890320.qNNyVx8cQd
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGdxvanKMhG6pzZJIRAk4iAJ9Dq2R9w+O3YG7+hOy32wIa0TnloACfYfQL
O3PYFDKKktRw+YPPNHt0BJs=
=2Dyu
-----END PGP SIGNATURE-----

--nextPart1890320.qNNyVx8cQd--