I think this bug would be resolved by bug 114796, where you could assign the play/pause button to a command that would perform the requested action (such as binding to "totem --play" for example). Having a key binding that performs two different operations depending on the current context is likely to be confusing.

*** This bug has been marked as a duplicate of 114796 ***

I disagree rather strongly.

Special keys are there to work around the GUI menu for people not technical enough to put shortcuts to the relevant programs on their panels or desktops

While bug #114796 is nice for technical users and special uses, forcing the use of the CLI to assign a shortcut to such a common action as play is thoroughly missing the point about special keys (aka multimedia keys, remember) 

Home users use
1. a browser
2. a multimedia player
3. a mail agent (SPAM made webmail a popular choice for lots of people today)

There is really no excuse to have 2. depend on a manually assigned CLI command. 2. is no longer an optional feature nowadays - multimedia graduated to core OS feature a few years ago, users don't want a return to the bad old I'll-install-a-specific-player winamp days.

I'm still not convinced that using the play/pause action to start a media player isn't confusing. For example, if you have a movie player playing, and wish to pause it, you would not want your preferred media player starting when you pressed your play/pause button on the keyboard.

(In reply to comment #3)
> I'm still not convinced that using the play/pause action to start a media
> player isn't confusing. For example, if you have a movie player playing, and
> wish to pause it, you would not want your preferred media player starting when
> you pressed your play/pause button on the keyboard.

With the new code we can actually tell whether a media player is listening or not.

So wouldn't this be even more confusing? For example, if you had been watching a movie in Totem, and paused it, and then wanted to listen to some music, pressing the play/pause keyboard button would start Totem playing again. The user might have expected that it would have opened their music player based on previous experience when Totem was not open.

As I said, we know whether there's a media player listening, so we would only launch the player if there wasn't a player listening for events. But I agree that launching it solely on the basis that play/pause was typed is wrong.

What I meant was that if the user happened to have another player (e.g. totem) already listening for the event somewhere in the background or minimized, then the user may expect to start their default player by using play/pause. This wouldn't happen and instead the existing player (e.g. totem) would respond to the play/pause.

Nicolas, do you have any comments on these thoughts?

Yeah, the behaviour would be a bit too confusing, IMO.

(In reply to comment #7)

> Nicolas, do you have any comments on these thoughts?

1. play/pause should launch the default multimedia player if none is running (as evidenced by the fact enhanced keyboards do not sport a separate "launch player" button, while they have "launch browser/MUA/calculator" ones

2. default IMHO should be audio, audio+video in audio mode or audio+video in last used mode on last used content (video by itself is bad, remembering the previous state is good)

3. I don't really care if GNOME is smart enough to detect several players or only the default one. Both behaviours are OK, and people relying heavily on the MM buttons will only use one player anyway

(In reply to comment #9)
> (In reply to comment #7)
> 
> > Nicolas, do you have any comments on these thoughts?
> 
> 1. play/pause should launch the default multimedia player if none is running
> (as evidenced by the fact enhanced keyboards do not sport a separate "launch
> player" button, while they have "launch browser/MUA/calculator" ones

But it will break older applications that use XF86Play, etc. and don't implement the new D-Bus API.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > 
> > > Nicolas, do you have any comments on these thoughts?
> > 
> > 1. play/pause should launch the default multimedia player if none is running
> > (as evidenced by the fact enhanced keyboards do not sport a separate "launch
> > player" button, while they have "launch browser/MUA/calculator" ones
> 
> But it will break older applications that use XF86Play, etc. and don't
> implement the new D-Bus API.

I don't have a magic answer, but it's getting to the point finding a keyboard without a play button is harder than a keyboard with it, and people do expect it to launch a player. Too bad for legacy apps but one can not ignore hardware changes indefinitely.

I guess if we add a default media player, then this would be the only one the multimedia keys should interact with.

(In reply to comment #12)
> I guess if we add a default media player, then this would be the only one the
> multimedia keys should interact with.

No. The code is clever enough to know which is the last used application, so we can juggle with multiple applications (say, a movie and music player) and have the keys work as expected.

(In reply to comment #11)
> (In reply to comment #10)
> > But it will break older applications that use XF86Play, etc. and don't
> > implement the new D-Bus API.
> 
> I don't have a magic answer, but it's getting to the point finding a keyboard
> without a play button is harder than a keyboard with it, and people do expect
> it to launch a player. Too bad for legacy apps but one can not ignore hardware
> changes indefinitely.

My laptop keyboard doesn't have play/pause keys. And my desktop keyboard has a media button to launch the music/movie player.

I can add support for the Media key, I'm not willing to break older applications for the sake of it though, and I won't be making play launch the default media player.

So your problem is bug 373934, keybindings are mutually exclusive

There's already support for the media key, so closing this.