[vlc-devel] Re: [bmpx] Re: [Banshee-List] [bmpx] Re: Proposal for a common D-Bus interface for media players
William Pitcock
nenolod at atheme.org
Thu Dec 7 10:53:51 CET 2006
Hi there,
I think org.freedesktop.MediaPlayer would be fine. In the case of multiple
players, I think that unavailability of binding to the common org.freedesktop.MediaPlayer
object should not block however.
If implemented correctly, this would be perfect. However, some other
issues arise:
- What if the user wants to switch his preferred media player from Amarok to
BMPx, Videolan, Audacious or XMMS2?
+ We could send a signal to the other player saying that it is OK to
takeover the common interface, but if an application is slow to
release the interface, the other player may not successfully bind
to the org.freedesktop.MediaPlayer instance like desired.
Other than that concern, it sounds really good, and I hope to see this
work out in this way.
- William
On Thu, 7 Dec 2006, Milosz Derezynski wrote:
> Yeah, that, in fact, does very much make sense. As long as this player
> exposes the common specced interface on org.freedesktop.MediaPlayer, it'd be
> perfectly ok.
>
> This idea should be really taken under consideration. Anyone's other's
> comments on this?
>
> Milosz
>
> On 12/6/06, Brian Nickel <brian.nickel at gmail.com> wrote:
>>
>> For running multiple media players, wouldn't it be easiest to have each
>> player have its own DBus object that implements the common library (with
>> their own player specific features on top) and in addition have a second
>> common DBus object "org.freedesktop.MediaPlayer" which points to the
>> object or contains the object (I have little knowledge of how DBus works),
>> so that when a player starts up it can launch its own DBus object and then
>> attempt to take control of the universal name. If it fails to get the
>> universal name, it will still work, but no calls to the universal name
>> will
>> get to it, just direct calls to its own object.
>>
>> I hope that made sense.
>>
>> - Brian
>>
>> On Wed, 2006-12-06 at 06:04 +0100, Milosz Derezynski wrote:
>>
>> Allright as i've read on the transcript, you're going to implement the
>> DBus interace as a "client" anyway.
>>
>>
>> So for one: nevermind the part about "DBus or nothing", but then again
>> what is your concern with running one player, and debugging XMMS2 the same
>> time?
>> Milosz
>>
>> On 12/6/06, *Milosz Derezynski* <internalerror at gmail.com> wrote:
>>
>> Sham:
>> Yeah it would basically mean that one player can run at a time, but going
>> with what Diego said earlier, i'd concur that it could be very well
>> something that is not directly at the core of the application, and it can
>> be
>> started without exposing itself through DBus. BMPx can do this in fact if
>> you start it with the -bin binary and pass --no-remote to it.
>>
>> (For those unfamiliar with what i mean with -bin binary: BMPx implements a
>> single-application-instance/application-as-service [1] mechanism using
>> DBus
>> activation. There is a 'remote' binary which is for all intents and
>> purposes
>> for the user just like the main application binary, and a "-bin" binary
>> (similar to firefox-bin for firefox/comparable) in libexec)
>>
>> Furthermore, and i'm aware i might be digging up probably unpleasant stuff
>> i see the problem with XMMS2+DBus the one that there is no "real" reason
>> for
>> XMMS2 to not switch to DBus (yeah i know about tru's technical
>> explanations
>> and the don't-broadcast and no TCP/IP transport stuff but that will
>> appear,
>> well anyway back to the main sentence), so, basically, once XMMS2
>> implements
>> a DBus interface using this common spec, there would be no _real_ reason
>> to
>> not to switch to DBus entirely for server<->client messaging (XMMS2 to
>> clients for those not in the know).
>>
>> So either this will happen (you switch entirely), or you guys will just
>> not switch to DBus at all; everything else is just unfeasible if not at
>> the
>> very least from a maintenance point of view, and it would be obviously
>> also
>> hilarious because of other reasons to implement 2 very similar systems of
>> which either could replace the other (except that without DBus, there will
>> be hardly a common interface implemented.)
>>
>> I just want to point this out right now and bring it to the surface,
>> before we all start a chanty dance around an empty pot.
>>
>> Everyone:
>>
>> As for the table, it's something Sham has done some good while ago and
>> it's a good starting point to see how common the current interfaces are.
>>
>> Sham (again):
>>
>> Can you wiki-fy the table and make it editable (perhaps only on request
>> and only for people you approve for, well, namely the media player
>> developers or the players listed there at the least, so we can quickly
>> amend
>> it, etc.. ?
>>
>> Regards,
>> Milosz
>>
>> [1] http://live.gnome.org/DesktopAppsAsDBusServices (NOTE: We actually
>> deployed this mechanism 1 year before Alex proposed it in his form, so our
>> implementation differs in details, but is essentially the same; it doesn't
>> go -as- far as putting stuff into .desktop files that could be regarded as
>> bogus until really accepted as a spec/way to do things)
>>
>>
>>
>> On 12/6/06, *Sham Chukoury* <eleusis at xmms.org> wrote:
>>
>> Hello world.
>>
>> Seb Ruiz wrote:
>> > Actually, whilst I was in san francisco, I spoke with the xmms2 folks
>> > about the same thing. we totally agreed on the necessity for it.
>>
>> Indeed, this was discussed a bit during a meeting: [1]
>> (full transcript at [2])
>>
>> > > I've been working recently of a D-Bus [2] control interface for VLC,
>> > > to permit other applications to interact with VLC.
>> > > This implements basic functions such as:
>> > > - playback control (Play/Pause/Next..)
>> > > - information on medias (Meta-data/Length)
>> > > - playlist editing (Add new elements to play)
>> > >
>> > > I've been looking at how other media players already implemented that,
>> > > and I thought all their interfaces were highly redundant, and could
>> > > benefit of implementing a single, common, shared interface.
>> > >
>> > > That would let developers use this interface in their programs, and
>> > > let their users decide of which media player they wanna use. All about
>> > > FREEDOM.
>>
>> I've done a bit of work on this, though in the form of a Python library
>> (Chalyx
>> - for XMMS2 [3] and MPD [4] clients), not an open spec or interface of any
>> kind.
>> You can see the class defining the methods to be used at [5]
>> It's a bit of a compromise between the interfaces provided by XMMS2 [6]
>> and MPD
>> [7] (though biased a bit towards XMMS2). You can see a table comparing the
>>
>> interfaces at [8] (Some MPRIS/BMP/BMPx calls are included, but they've
>> never
>> been implemented in Chalyx)
>>
>> > > I've copied this specification on the videolan wiki [6], and modified
>> > > it to my needs. I tried to keep it as general as possible. However
>> > > this still needs more work, and comments.
>> > >
>> > > This is why i'm reaching you, developers of some media players, to
>> > > comment what i've done or work with me, until that specification
>> > > fulfills your needs, and can be used in a real world.
>> > >
>> > > This specification should stay as generic as possible, because media
>> > > players that want to make specific methods available with D-Bus can do
>> > > it through their specific interface.
>> > >
>> > > For example, basic methods would be available on the service
>> > > org.freedesktop.MediaPlayer and VLC would make streaming methods
>> > > available on the service org.videolan.vlc. So, a basic control applet
>> > > for the KDE panel originally written for amarok would be able to
>> > > control VLC, and a complex pygtk script would control streaming
>> > > features of VLC.
>>
>> Re: 'The Service' on the DBus-spec page, am I to understand that only one
>> player
>> supporting the spec may be running at any one time? That makes sense from
>> the
>> point of view that the user might want a single 'default' player to
>> control, but
>> what if the user wants 2 such players running at a time? For example,
>> listening
>> to music using VLC while debugging XMMS2? ;)
>>
>> Re: generic interface, does that mean there could be standard interface
>> extensions? For example, players with access to a media library could have
>> an
>> extended interface 'org.freedesktop.MediaPlayer.Library'.
>>
>> Cheers.
>> -S
>>
>> [1]
>>
>> http://wiki.xmms2.xmms.se/index.php/IRC_Meeting/2006-11-27/Minutes#Amarok_and_XMMS2_Collaboration
>> [2] http://dan.chokola.com/files/xmms2-meeting/2006-11-27/transcript.txt
>> [3] http://xmms2.xmms.se/epydoc/public/xmmsclient.XMMS-class.html
>> [4] http://mpd.wikia.com/wiki/MusicPlayerDaemonCommands
>> [5]
>> http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/service.py
>> [6]
>> http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/xmms2.py
>> [7]
>> http://git.xmms.se/?p=chalyx-eleusis.git;a=blob;f=src/Chalyx/services/mpd.py
>> [8]
>> http://xmms2.xmms.se/~eleusis/misc/client-api-table.html<http://xmms2.xmms.se/%7Eeleusis/misc/client-api-table.html>
>>
>>
>>
>>
>> _______________________________________________Banshee-list mailing
>> listBanshee-list at gnome.orghttp://mail.gnome.org/mailman/listinfo/banshee-list
>>
>>
>
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel
mailing list