XEmbed-aware NPAPI Plugins?

[Mike Melanson]

Hi,

Are there any plans to adapt Konqueror (now KFM?) to use XEmbed to
instantiate NPAPI plugins (such as the Flash Player)?

Thanks...

[Kevin Krammer]

Hi Mike,

Post by Mike Melanson
Hi,
Are there any plans to adapt Konqueror (now KFM?) to use XEmbed to
instantiate NPAPI plugins (such as the Flash Player)?

I am not sure I understand the question correctly.
Do you mean "adapt" in the sense of doing differently than we do now or in
changing to a new version of the NPAPI?

Cheers,
Kevin

P.S.: KFM has been the name of the filemanager in KDE1, it's been Konqueror
since KDE2

[Mike Melanson]

Post by Kevin Krammer
Hi Mike,

Post by Mike Melanson
Hi,
Are there any plans to adapt Konqueror (now KFM?) to use XEmbed to
instantiate NPAPI plugins (such as the Flash Player)?

I am not sure I understand the question correctly.
Do you mean "adapt" in the sense of doing differently than we do now or in
changing to a new version of the NPAPI?

Not a new version of NPAPI.

Mozilla implements XEmbed for embedding plugins on X, which differs (in
good ways) from the classical Xt mainloop method (though it still
supports the old method). The API (from the plugin's perspective) is here:

http://www.mozilla.org/projects/plugins/xembed-plugin-extension.html

I've seen the code on Mozilla and it seems pretty simple from the
hosting app angle, too (query the plugin to ask if it supports XEmbed,
if yes, create an XEmbed socket and pass it to the plugin via SetWindow()).

I'm interested because I'm working on upgrading a NPAPI plugin from Xt
mainloop to XEmbed.

Post by Kevin Krammer
P.S.: KFM has been the name of the filemanager in KDE1, it's been Konqueror
since KDE2

Ooops, I mis-read the mailing list page and got it backwards. Good; I
think Konqueror is a cooler name than KFM.

[Kevin Krammer]

Post by Mike Melanson

Post by Kevin Krammer
Hi Mike,

Post by Mike Melanson
Hi,
Are there any plans to adapt Konqueror (now KFM?) to use XEmbed to
instantiate NPAPI plugins (such as the Flash Player)?

I am not sure I understand the question correctly.
Do you mean "adapt" in the sense of doing differently than we do now or
in changing to a new version of the NPAPI?

Not a new version of NPAPI.
Mozilla implements XEmbed for embedding plugins on X, which differs (in
good ways) from the classical Xt mainloop method (though it still
http://www.mozilla.org/projects/plugins/xembed-plugin-extension.html

I see, thanks for clarifying.

I think we already use XEmbed or something similar for plugins because we run
them out of process as part of nspluginviewer, in which case it might not be
very difficult to check if the plugin can do its side of XEmbed itself.

However, you better wait for an answer of the developers with in-depth
knowlegde of browser and/or plugin handling (please excuse the CC'ing guys)

Post by Mike Melanson
I've seen the code on Mozilla and it seems pretty simple from the
hosting app angle, too (query the plugin to ask if it supports XEmbed,
if yes, create an XEmbed socket and pass it to the plugin via SetWindow()).
I'm interested because I'm working on upgrading a NPAPI plugin from Xt
mainloop to XEmbed.

Adobe Flash plugin, correct?

Cheers,
Kevin

[Mike Melanson]

Post by Kevin Krammer

Post by Mike Melanson

Post by Kevin Krammer
Hi Mike,

Post by Mike Melanson
Hi,
Are there any plans to adapt Konqueror (now KFM?) to use XEmbed to
instantiate NPAPI plugins (such as the Flash Player)?

I am not sure I understand the question correctly.
Do you mean "adapt" in the sense of doing differently than we do now or
in changing to a new version of the NPAPI?

Not a new version of NPAPI.
Mozilla implements XEmbed for embedding plugins on X, which differs (in
good ways) from the classical Xt mainloop method (though it still
http://www.mozilla.org/projects/plugins/xembed-plugin-extension.html

I see, thanks for clarifying.
I think we already use XEmbed or something similar for plugins because we run
them out of process as part of nspluginviewer, in which case it might not be
very difficult to check if the plugin can do its side of XEmbed itself.
However, you better wait for an answer of the developers with in-depth
knowlegde of browser and/or plugin handling (please excuse the CC'ing guys)

Post by Mike Melanson
I've seen the code on Mozilla and it seems pretty simple from the
hosting app angle, too (query the plugin to ask if it supports XEmbed,
if yes, create an XEmbed socket and pass it to the plugin via SetWindow()).
I'm interested because I'm working on upgrading a NPAPI plugin from Xt
mainloop to XEmbed.

Adobe Flash plugin, correct?

Yes, that's the one.

[Maksim Orlovich]

Post by Kevin Krammer

Post by Mike Melanson
Not a new version of NPAPI.

Coincidentally, I had WIP versions with partial support of npruntime, but
they're rather useless since they make flash crash badly.. I'll probably
try again in KDE4 where I can implement everything, not just a subset of
functionality.

Post by Kevin Krammer

Post by Mike Melanson
Mozilla implements XEmbed for embedding plugins on X, which differs (in
good ways) from the classical Xt mainloop method (though it still
http://www.mozilla.org/projects/plugins/xembed-plugin-extension.html

I see, thanks for clarifying.
I think we already use XEmbed or something similar for plugins because we run
them out of process as part of nspluginviewer, in which case it might not be
very difficult to check if the plugin can do its side of XEmbed itself.

It would be very difficult. nspluginviewer has non-trivial communication
with the browser. When it comes to embedding the plugin inside
nspluginviewer, well... I can't speak for George, of course, but when I
looked at the spec and the examples before, I frankly found it very
problematic (and not much of a spec), and wasn't sure that implementing it
won't break tons of plugins... Besides the XEmbed flag, the ABI revision
also comes with a "tookit flag", which has only 2 specified values: Gtk
1.2 and Gtk 2.0. And, well, the examples they have encourage plugin
authors to check that:
err = CallNPN_GetValueProc(gNetscapeFuncs.getvalue, NULL,
NPNVSupportsXEmbedBool,
(void *)&supportsXEmbed);

if (err != NPERR_NO_ERROR || supportsXEmbed != PR_TRUE)
return NPERR_INCOMPATIBLE_VERSION_ERROR;

err = CallNPN_GetValueProc(gNetscapeFuncs.getvalue, NULL,
NPNVToolkit,
(void *)&toolkit);

if (err != NPERR_NO_ERROR || toolkit != NPNVGtk2)
return NPERR_INCOMPATIBLE_VERSION_ERROR;

And, frankly, I am not sure I'm confident that lying here will be safe.
(Coincidentally, depending on which ABI version this is at, we might have
to provide fake versions of some gtk symbols to make Flash 7 not crash)

Post by Kevin Krammer
However, you better wait for an answer of the developers with in-depth
knowlegde of browser and/or plugin handling (please excuse the CC'ing guys)

Good job CCing the wrong people :p

-Maks

[Mike Melanson]

Post by Maksim Orlovich

Post by Kevin Krammer

Post by Mike Melanson
Mozilla implements XEmbed for embedding plugins on X, which differs (in
good ways) from the classical Xt mainloop method (though it still
http://www.mozilla.org/projects/plugins/xembed-plugin-extension.html

I see, thanks for clarifying.
I think we already use XEmbed or something similar for plugins because we run
them out of process as part of nspluginviewer, in which case it might not be
very difficult to check if the plugin can do its side of XEmbed itself.

It would be very difficult. nspluginviewer has non-trivial communication
with the browser. When it comes to embedding the plugin inside
nspluginviewer, well... I can't speak for George, of course, but when I
looked at the spec and the examples before, I frankly found it very
problematic (and not much of a spec), and wasn't sure that implementing it
won't break tons of plugins... Besides the XEmbed flag, the ABI revision
also comes with a "tookit flag", which has only 2 specified values: Gtk
1.2 and Gtk 2.0. And, well, the examples they have encourage plugin
err = CallNPN_GetValueProc(gNetscapeFuncs.getvalue, NULL,
NPNVSupportsXEmbedBool,
(void *)&supportsXEmbed);
if (err != NPERR_NO_ERROR || supportsXEmbed != PR_TRUE)
return NPERR_INCOMPATIBLE_VERSION_ERROR;
err = CallNPN_GetValueProc(gNetscapeFuncs.getvalue, NULL,
NPNVToolkit,
(void *)&toolkit);
if (err != NPERR_NO_ERROR || toolkit != NPNVGtk2)
return NPERR_INCOMPATIBLE_VERSION_ERROR;
And, frankly, I am not sure I'm confident that lying here will be safe.
(Coincidentally, depending on which ABI version this is at, we might have
to provide fake versions of some gtk symbols to make Flash 7 not crash)

How about Flash Player 9 (latest version)?

Querying for a specific toolkit somewhat undermines the goal of XEmbed.
I thought XEmbed was supposed to allow, for example, putting GTK apps
inside KDE apps, which is the goal here.

There are no public versions of the Adobe Flash Player for Linux that
presently support XEmbed right now. But the stuff I'm working on right
now does not query for underlying toolkit support.

[Maksim Orlovich]

Post by Mike Melanson
How about Flash Player 9 (latest version)?

Definitely not that particular bug / not that obviously -- as I said, I
had quite a few crashes when trying to implement npruntime, but it's just
hard to say whose fault they were, as the implementation was incomplete as
well. (Though it could do stuff like find out the number of frames, etc.).
I am just not very good at debugging stuff w/a stripped library...

What Flash 7 used to do was something like:
*(int*)dlsym("gtk_major_version") for some ABI revisions. Which, of
course, crashes with a null pointer exception w/nspluginviewer.

Post by Mike Melanson
Querying for a specific toolkit somewhat undermines the goal of XEmbed.
I thought XEmbed was supposed to allow, for example, putting GTK apps
inside KDE apps, which is the goal here.

I would definitely agree with that, and in our end, it may be nicer not to
use Xt (though I am not sure supporting both Xt and XEmbed wouldn't be
scarier).

Post by Mike Melanson
There are no public versions of the Adobe Flash Player for Linux that
presently support XEmbed right now. But the stuff I'm working on right
now does not query for underlying toolkit support.

This is very, very, good to hear, and might mean that I might try to do
the XEmbed thing, if I can find something to test with, though it's in no
way guaranteed --- way too much other stuff to do, and npruntime support
would be more important... Flash is basically -the- critical plugin we
care about, just about everything else is replaceable natively.

Thanks,
Maks

[Kevin Krammer]

Post by Maksim Orlovich

Post by Kevin Krammer
However, you better wait for an answer of the developers with in-depth
knowlegde of browser and/or plugin handling (please excuse the CC'ing guys)

Good job CCing the wrong people :p

:)
I CCed George because he's listed in the copyrights of nspluginviewer files,
David, because he seems to know everything and Koos because he does (AFAIK)
some kind of embedding in KMPlayer (and, AFAIK, in the original Gnash<->KDE
integration)

Somehow the mail received by the list does not show George as being part of
the CC list, while the mail in my "sent" folder does.

I know all of them are also subscribed here, but as we all know, sometimes we
skip threads and only later find out they would have been important.

Since it is usually almost impossible to get corporate developers to contact
us for information, I didn't want to see this opportunity wasted.

Cheers.
Kevin

[Mike Melanson]

Post by Mike Melanson
Hi,
Are there any plans to adapt Konqueror (now KFM?) to use XEmbed to
instantiate NPAPI plugins (such as the Flash Player)?

If anyone is interested in adding XEmbed plugin support to Konqueror, I
have published a simple, XEmbed-aware, open source, NPAPI plugin:

http://multimedia.cx/diamondx/

I'm hoping this can help bridge the gap between Linux web browsers and
the Flash plugin. This first release addresses XEmbed and events.
Eventually, I hope it will be a testbench for making windowless plugins
a reality in Unix browsers.