Controlling "current" concept via D-Bus

[Thiago Macieira]

Andreas Hartmetz wrote:
>> It's possible to use the D-Bus connection name structure for this
>> task. If there's interest, I can show some proof-of-concept code.
>
>If this would still be needed when a generic e.g. media player manager
> is availabe, yes please. But only if it doesn't take you too much time.
> I might ask you some DBus questions in the future >:}

I will use the Media Player concept here as an example. I will post some 
example code later on.

Suppose the user has 3 media players installed:
	Noatun
	Amarok
	kscd

None of them are running at the moment. Each KDE application by default 
gets its own D-Bus connection name upon starting (org.kde.noatun, 
org.kde.amarok and org.kde.kscd). Those aren't affected at all by the 
discussion that follows.

1) user starts Noatun
2) Noatun registers the name org.kde.mediaplayer with a flag of 
AllowReplacement
3) the D-Bus daemon grants Noatun the name

4) user starts Amarok
5) Amarok registers as well the name org.kde.mediaplayer with a flag of 
AllowReplacement
6) the D-Bus daemon sees this new registration and grants Amarok the name, 
telling Noatun that it lost the name

7) user presses Play in the manager interface, which makes a call to 
org.kde.mediaplayer to start playing. In this case, it's Amarok that 
starts playing.
8) Amarok receives the Play command and re-registers the 
org.kde.mediaplayer, this time with the DontAllowReplacement flag

9) user starts kscd
10) kscd tries to register the name org.kde.mediaplayer (AllowReplacement)
11) the D-Bus daemon denies this registration so the name stays with 
Amarok

12) user presses Stop in Amarok, the media player or using the global 
shortcut
13) Amarok again re-registers the name org.kde.mediaplayer, but with 
AllowReplacement

At this point, if the user presses Play in Noatun or kscd, the D-Bus 
daemon will grant that player the name, taking it from Amarok.

The features of this process are:
a) if no player has started playing, the player started last will be 
the "current" player → most recent = most likely top of mind
b) if a player is playing, no other can take over the "currentness"
c) the player that was playing but stopped is also the "current" one → 
most recent
d) if the user wants to switch players, he has to use that one's 
interface, not the manager

Bugs:
if the user quits the current player, which one will become "current" is 
undefined

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070511/400f1f06/attachment.sig>