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