Re: [Muine] [vlc-devel] Re: [bmpx] Re: [Banshee-List] [bmpx] Re: Proposal for a common D-Bus interface for media players
- From: William Pitcock <nenolod atheme org>
- To: Peter Stuge <stuge-xmms2 cdy org>
- Cc: xmms2-devel lists xmms se, rhythmbox-devel gnome org, vlc-devel videolan org, muine-list gnome org, bmpx beep-media-player org, banshee-list gnome org, Amarok Mailing List <amarok kde org>
- Subject: Re: [Muine] [vlc-devel] Re: [bmpx] Re: [Banshee-List] [bmpx] Re: Proposal for a common D-Bus interface for media players
- Date: Thu, 07 Dec 2006 10:06:10 -0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]