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 _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
