Swfdec/Konqi integration

Hi,

I'm the Swfdec developer. In recent times people have come
to me
wondering why the swfdec-mozilla plugin doesn't work in
Konqueror. All
I could say was "I have no clue, it should just
work."

My knowledge about Browser plugins is just enough to make
Swfdec work
in Mozilla-based browsers and certainly doesn't extend to
Konqueror,
but as I said: It should just work.

Has anybody of you guys had a look at it recently or could I
make you?

Benjamin

On 2-May-07, at 3:47 PM, Benjamin Otte wrote:

> Hi,
>
> I'm the Swfdec developer. In recent times people have
come to me
> wondering why the swfdec-mozilla plugin doesn't work in
Konqueror. All
> I could say was "I have no clue, it should just
work."
>
> My knowledge about Browser plugins is just enough to
make Swfdec work
> in Mozilla-based browsers and certainly doesn't extend
to Konqueror,
> but as I said: It should just work.
>
> Has anybody of you guys had a look at it recently or
could I make you?

   I wrote a swfdec KPart years ago but swfdec really didn't
do much  
so it wasn't all that useful.  If that's changed, kswfdec
might be  
useful again.

    Beyond that, it's probably some quirk in the nsplugin
host or a  
missing library dependency.  At least those are the usual
culprits.

--
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/

On Freitag, 4. Mai 2007 +0100, Eva Brucherseifer wrote:
> Am Freitag, 4. Mai 2007 schrieb Mike Melanson:
> > George Staikos wrote:
> > >>>   Plugins need to stop assuming that
Linux == Gtk.
> > >>
> > >> What should they assume instead?
> > >
> > >    When you assume you make an .....
> >
> > To be serious about this, per my understanding,
plugin authors are
> > supposed to be able to use XEmbed to write their
stuff using one toolkit
> > and have it run neatly embedded in another app,
even if that other app
> > is using another toolkit.
>
> With software being crossplatform you can't assume you
have xembed
> available. KDE is heading towards mac, windows,
embedded - all without X.
> In contrast to that gtk and Qt are both much better,
because they actually
> support those platform, while Qt's support is probably
the best.

True, but I think there isn't any plugin embedding mechanism
that works on all 
those platforms and does not depend on a specific toolkit.

Su using XEmbed on X11 is already an improvement, as a
plugin only needs to 
know about three embedding mechanisms, one for each
windowing system.

Of course toolkits could still be able to abstract this for
their users, e.g. 
offer a PluginHostWidget that uses the respective windowing
system's 
embedding mechanism like they already do for other windowing
system specific 
stuff.

Cheers,
Kevin

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

Hi Maksim!

2007/5/3, Maksim Orlovich <mo85cornell.edu>:
> > But nspluginviewer now uses qxembed to embed in
the nsplugin and dcop
> > for communications. Latter probably dbus in kde4.
So why not
> > completely write nspluginviewer in gtk using
gtkplug?
>
> Do you have a volunteer in mind?

If nobody has an alternative solution, I'm willing to
implement this.

> I sure as heck am not doing that,
> and I would not implement npruntime either if
nspluginviewer used gtk.

That would be a real pitty. Maybe we could find some way to
split this
Xt based current version and the new one. So you could add
your code
to the current one and either the other one doesn't support
this or code
could be ported (by me).

Koos

2007/5/7, koos vriezen <koos.vriezengmail.com>:
> 2007/5/3, Maksim Orlovich <mo85cornell.edu>:
> > > But nspluginviewer now uses qxembed to embed
in the nsplugin and dcop
> > > for communications. Latter probably dbus in
kde4. So why not
> > > completely write nspluginviewer in gtk using
gtkplug?
> >
> > Do you have a volunteer in mind?
>
> If nobody has an alternative solution, I'm willing to
implement this.

See http://zrusin.blogspot.com/2007/05/browser-plugins.html , already
more generally done in webkit so it seems.

I'm just out of the copy&paste phase of
http://devedge-temp.mozilla.org/library/manuals/
2002/plugin/1.0/
.Plugin loading works for mimetype querying. I guess I can
stop now.

Koos

2007/5/27, koos vriezen <koos.vriezengmail.com>:
> 2007/5/7, koos vriezen <koos.vriezengmail.com>:
> > 2007/5/3, Maksim Orlovich <mo85cornell.edu>:
> > > > But nspluginviewer now uses qxembed to
embed in the nsplugin and dcop
> > > > for communications. Latter probably dbus
in kde4. So why not
> > > > completely write nspluginviewer in gtk
using gtkplug?
> > >
> > > Do you have a volunteer in mind?
> >
> > If nobody has an alternative solution, I'm willing
to implement this.

I've made a setup that for now is in the kmplayer extragear
kde3
branch, so users wont be surprised the plugin doesn't work
on youtube

Anyhow it's a nice standin for nsplugin for the kde3 cycle
for
flash.
(haven't followed development in trunk, so maybe it's too
late already)

Anyhow, streams are directly streamed to the knpplayer
process. Of
course not optimal, but first saving to file is even less I
think ..
Added some basic npruntime stuff that Adobe seem to ask
for.

Source code is at http://kmplayer.kde.org/pkgs/kmplayer-0.10.0-pre1.tar.b
z2

Build requires dbus-1-qt/gtk as well as nspr development
package.

Works pretty well with the Adobe beta release. To use it,
run the
kmplayer application once to get a config file. Then edit
~/.kde/share/config/kmplayerrc and add

[application/x-shockwave-flash]
player=npp
plugin=/home/koos/.mozilla/plugins/libflashplayer.so

(I've used a chroot'ed setup for this. only compile
npplayer.c in there)

Now configure konqueror's file assoc. to use 'Embedded
MPlayer for
KDE', as default for this mime type.
And that should be it.

The swfdec from debian/unstable (which needs hacking on the
package to
get it installed) worked originally but filled my RAM quite
soon.
Upgrading to 0.4.5 has this problem that the window wherein
it's embed
resizes by the plugin loading of konqueror. Actually the
initial
parent isn't visible first.
Calling SetWindow multiple times seem to help, but I wonder
why is
chosen for the hard 'gdk_window_foreign_new' way and not for
the
'gtk_plug_new' way.
Btw. the times the swfdec worked, it worked pretty well. I
really like
that it first starts in paused state. It actually never
crashed on me,
though refused to play some videos on youtube. I think the
0.4.3
doesn't work anymore, last time I downgraded, I got fatal
BadMatch
errors.

Koos

Hi Kevin,

2007/6/18, Kevin Krammer <kevin.krammergmx.at>:
[..]
> Awesome work!

Thanks 

> >  Anyhow
it's a nice standin for nsplugin for the kde3 cycle for
> >
> > flash.
> > (haven't followed development in trunk, so maybe
it's too late already)
>
> Well, if possible we should have an option for a plugin
viewer for the 3.5
> series, since this is what "enterprise"
distributions will be distributing
> for a while.

Only this one is for new style xembed types. So we may have
two. And
its all mimetype based anyhow.

> One of the comments on Zack's blog about browser
plugins suggested that the
> Mozilla/Firefox people might be interested in doing
plugins out-of-process as
> well and could even consider shared work on the plugin
runners.
>
> Therefore I tried to (didn't check the sources
thoroughly) extract the D-Bus
> interfaces (see attachment) Koos used in the XML format
used in D-Bus
> inttrospection and added a few comments.

Thanks. I hope you noticed it's more an ad-hoc interface
now. Like you
indeed noticed the 'getUrlNotify' and also 'finish' are odd
and based
on the fact that there is currently only one active stream.
And
streams are worked out sequentially.
This should be changed to something like
'requestStream(streamid)'/destroyStream(streamid) for the
plugin and
streamDone from the browser side kpart. Also the to stdin
streaming
should be send in chunks containing a header of its size and
streamid.
Data must be retrieved from the browser side for eg. auth.
reasons,
though ideally I would like to stream directly from
kioslaves of
course. Nevertheless, it's the xserver that uses most of the
CPU w/
flash movies.

'evaluate' is the only blocking call and should therefor
have a
non-blocking companion in case the result is not important.
Btw. the
way js objects are ref'ed is rather hacky of course.

Anyhow, this all should evolve a bit by supporting various
plugins.

Thanks for your comments,

Koos

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

On 6/17/07, koos vriezen <koos.vriezengmail.com> wrote:
> The swfdec from debian/unstable (which needs hacking on
the package to
> get it installed) worked originally but filled my RAM
quite soon.
>
I think 0.4.3 had a rather emberrassing memleak of not
freeing the
whole player instance when you had opened the properties
window. So
either install something newer or don't open properties
windows. ;)

> Upgrading to 0.4.5 has this problem that the window
wherein it's embed
> resizes by the plugin loading of konqueror. Actually
the initial
> parent isn't visible first.
> Calling SetWindow multiple times seem to help, but I
wonder why is
> chosen for the hard 'gdk_window_foreign_new' way and
not for the
> 'gtk_plug_new' way.
>
2 reasons: 1) it worked (i probably did something wrong with
the plug
thingy, but didn't care anymore) and 2) I wanted to go
windowless
anyway to support translucency and event passing properly.

> Btw. the times the swfdec worked, it worked pretty
well. I really like
> that it first starts in paused state. It actually never
crashed on me,
> though refused to play some videos on youtube.
>
Thanks. 
Not crashing is the primary goal of Swfdec, since every time
it
crashes it brings down the whole browser, and people really
dislike
that. ;)
As for the PAUSE mode, I plan to model it a bit like popup
handling:
If domain is unknown, start paused. If user clicks on it to
start
playing, whitelist the domain and start playing immediately
for
further Flash files from that domain. And of course allow a
properties
page for explicitly whitelisting and blacklisting domains.
But I
haven't implemented it, so I have no clue how well that
would works

Since I'm pretty convinced that the proper solution for
Swfdec is to
write a KPart that does the embedding and not rely on the
rather
stupid npplugin API, I don't really care about the hacks to
make it
work anymore. Add to this that I was invited to Akademy, so
I can grab
you in person and make sure we write it at the hackathon.
;)

Cheers,
Benjamin

koos vriezen said:
> Thanks. I hope you noticed it's more an ad-hoc
interface now. Like you
> indeed noticed the 'getUrlNotify' and also 'finish' are
odd and based
> on the fact that there is currently only one active
stream. And
> streams are worked out sequentially.
> This should be changed to something like
> 'requestStream(streamid)'/destroyStream(streamid) for
the plugin and
> streamDone from the browser side kpart.

No, there shouldn't.

Just use different object paths. There's absolutely no need
to stick IDs
into the API when you can use objects to do the same. One
object (path) =
one stream.

> Also the to stdin streaming
> should be send in chunks containing a header of its
size and streamid.

"streamid" being an object path.

> Data must be retrieved from the browser side for eg.
auth. reasons,
> though ideally I would like to stream directly from
kioslaves of
> course. Nevertheless, it's the xserver that uses most
of the CPU w/
> flash movies.

I'll add this: D-Bus is not a suitable transport for
transfer of large
blocks of data. It's not optimised for that. Please consider
using a
separate data channel, just like FTP.

PS: I plan implementing that very framework for KIO
RealSoonNow(TM).

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago
(AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358