Re: [Rhythmbox-devel] [vlc-devel] Re: [bmpx] Re: [Banshee-List] [bmpx] Re: Proposal for a common D-Bus interface for media players
- From: Anders Gustafsson <andersg 0x63 nu>
- To: William Pitcock <nenolod atheme org>
- Cc: xmms2-devel lists xmms se, rhythmbox-devel gnome org, vlc-devel videolan org, muine-list gnome org, bmpx beep-media-player org, Brian Nickel <brian nickel gmail com>, banshee-list gnome org, Amarok Mailing List <amarok kde org>
- Subject: Re: [Rhythmbox-devel] [vlc-devel] Re: [bmpx] Re: [Banshee-List] [bmpx] Re: Proposal for a common D-Bus interface for media players
- Date: Thu, 07 Dec 2006 11:22:34 +0100
William Pitcock wrote:
> 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?
I think this all is a non issue. First come first served should be fine.
If the user for some reason has multiple mediaplayers running (why? oh
why?) and doesn't want the player (s)he starts first to be the one
contactable through org.freedesktop.MediaPlayer (s)he unchecks the
"enable generic mediaplayer control" checkbox in the preferences of that
player.
IMHO the whole point of this interface is that is must be as simple as
possible.
Lets repeat what I wrote on our (XMMS2) wiki;
First, we need to ask the question: "What is the purpose of this interface?"
>From my point of view it should be an interface used by application that
primarily isn't controlling the media player. Some examples:
* VoIP application that wants to automatically stop playback when there
is an incomming call
* IRC client script that announces current track
* "enqueue in mediaplayer" in contextmenu in filebrowser
* some alarm clock app that starts music playback with a specific track
5 minutes before the real alarm goes on.
* dock/panel-app for showing current song.
* script that automatically stops music when your bluetooth phone goes
out of range.
* headphone saver (like screensaver, but that shuts off music instead)
* whatever, if the functionality is provided unexpected uses tend to pop up.
With a common interface this kind of apps doesn't have to know about
different media players, they just fire off some dbus messages to a
standard place.
To serve its purpose it must be very easy for the application to
interface with the mediaplayer. Therefore the interface has to be as
simple as possible, containing only the basic stuff, no capabilities
negotiation should be needed.
anders
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]