Re: [Rhythmbox-devel] [vlc-devel] Re: [bmpx] Re: [Banshee-List] [bmpx] Re: Proposal for a common D-Bus interface for media players

[William Pitcock <nenolod atheme org>]

I'm not entirely sure if it does. When I last looked at DBus 
documentation, around 0.90, I drew the conclusion that the binding to URIs 
in DBus was a instant-or-never affair. This may be changed now, but that 
doesn't solve the issue that a signal being sent out to the player that 
the user wants to switch control to will require some form of signaling.

An alternative to signalling, obviously, would be renaming the old 
interface; but I do not think that DBus will let you do that, and even 
if it does, it is probably context-limited; so some form of signaling may 
still be needed when the user wants to switch application contexts for 
control over MPRIS.

Anyway, MPRIS should have some form of provision for switching which 
application is getting the requests on demand without any sort of ugly 
closing + reopening apps.

For instance, consider the following workflow:

+ A user uses one of { XMMS1, Audacious, VLC } for casual listening, and
+ That same user uses one of { Amarok, Banshee, BMPx, Muine, Rhythmbox,
  XMMS2, Listen, mpd, ... } to listen to collections of music.

It may be desirable to be able to switch which one is under MPRIS' 
limelight on demand in this situation, as you may be using a jukebox one 
moment, and a simple player the next.

- William

On Thu, 7 Dec 2006, Peter Stuge wrote:

> On Thu, Dec 07, 2006 at 04:53:51AM -0500, William Pitcock wrote:
> > - 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.
>
> Does DBUS support bus mastering/bus sharing like some other buses? In
> that case it just uses timeouts.
>
> (Yes, I know it's not a hardware bus.)
>
>
> //Peter