[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-17 22:26:07
Message-ID: 200706180026.12733.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On Sunday 17 June 2007, koos vriezen wrote:
> 2007/5/27, koos vriezen <koos.vriezen@gmail.com>:
> > 2007/5/7, koos vriezen <koos.vriezen@gmail.com>:
> > > 2007/5/3, Maksim Orlovich <mo85@cornell.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

Awesome work!

> :-) 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.

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.

Cheers,
Kevin

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

["introspection.xml" (text/xml)]

<!-- D-Bus interface of the browser / plugin embedder -->
<node>
    <interface name="org.kde.kmplayer.callback">
        <method name="getUrl">
            <arg name="url"    type=s" direction="in" />
            <arg name="target" type=s" direction="in" />
        </method>

        <method name="finish">
        </method>

        <method name="plugged">
        </method>

        <method name="running">
            <!-- service_name here is a requested D-Bus connection name
                 in the form of org.kde.kmplayer.npplayer-$PID
                 Might be sufficient to pass the unique name.
                 Another option would be that the browser passes the desired
                 name to the runner as a commandline parameter and the
                 browser then listens for the NameOwnerChanged signal -->
            <arg name="service_name" type=s" direction="in" />
        </method>

        <method name="evaluate">
            <arg name="script" type=s" direction="in" />
            <arg name="result" type=s" direction="out" />
        </method>
    </interface>
</node>

<!-- D-Bus interface of the plugin runner/viewer -->
<node>
    <interface name="org.kde.kmplayer.backend">
        <method name="play">
            <arg name="url"         type="s"     direction="in" />
            <arg name="mime_type"   type="s"     direction="in" />
            <arg name="plugin"      type="s"     direction="in" />
            <!-- D-Bus interfaces usually do not have length parameters for
                 "array" types, so this should probably be removed -->
            <arg name="param_count" type="u"     direction="in" />
            <arg name="params"      type="a{ss}" direction="in" />
        </method>

        <!-- Not sure what this does exactly, might be a candidate for a
             D-Bus signal -->
        <method name="getUrlNotify">
            <arg name="total"  type="u" direction="in" />
            <arg name="reason" type="u" direction="in" />
        </method>

    </interface>
</node>

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

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