New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable media keys actions #23

Closed
kav2k opened this Issue Oct 18, 2013 · 10 comments

Comments

Projects
None yet
5 participants
@kav2k

kav2k commented Oct 18, 2013

Spotify now natively supports media keys. This means that play-pause key now acts twice, being essentially useless, if this wrapper is used.

This must be dealt with somehow: either completely removing the feature, or making it optional.

@jreese

This comment has been minimized.

Show comment
Hide comment
@jreese

jreese Oct 18, 2013

Owner

What version of Spotify, and on what desktop environment and version?

Owner

jreese commented Oct 18, 2013

What version of Spotify, and on what desktop environment and version?

@kav2k

This comment has been minimized.

Show comment
Hide comment
@kav2k

kav2k Oct 18, 2013

Eh, sorry, left the office already. 

OS: Ubuntu 12.04 32 bit
Default environment for that, I'm not sure how to check. 

Spotify package version: 1:0.9.4.183.g644e24e.428-1

-------- Original message --------
From: John Reese notifications@github.com
Date:
To: jreese/spotify-gnome spotify-gnome@noreply.github.com
Cc: Alexander Kashev kav2k@ya.ru
Subject: Re: [spotify-gnome] Disable media keys actions (#23)

What version of Spotify, and on what desktop environment and version?


Reply to this email directly or view it on GitHub.

kav2k commented Oct 18, 2013

Eh, sorry, left the office already. 

OS: Ubuntu 12.04 32 bit
Default environment for that, I'm not sure how to check. 

Spotify package version: 1:0.9.4.183.g644e24e.428-1

-------- Original message --------
From: John Reese notifications@github.com
Date:
To: jreese/spotify-gnome spotify-gnome@noreply.github.com
Cc: Alexander Kashev kav2k@ya.ru
Subject: Re: [spotify-gnome] Disable media keys actions (#23)

What version of Spotify, and on what desktop environment and version?


Reply to this email directly or view it on GitHub.

@jreese

This comment has been minimized.

Show comment
Hide comment
@jreese

jreese Oct 21, 2013

Owner

Hmm, I'm running 0.9.4.183 on my own machine as well, but I'm running Gnome/Gnome Shell 3.10 on Arch linux, and I can't replicate the problem. I would likely suspect that either spotify-gnome is somehow executing twice, or that Ubuntu's Unity shell has added support for sending MPRIS media key signals. As a workaround, you could remove "MediaKeysHandler" from line 303 in the script so that it only handles notifications and Telepathy.

Owner

jreese commented Oct 21, 2013

Hmm, I'm running 0.9.4.183 on my own machine as well, but I'm running Gnome/Gnome Shell 3.10 on Arch linux, and I can't replicate the problem. I would likely suspect that either spotify-gnome is somehow executing twice, or that Ubuntu's Unity shell has added support for sending MPRIS media key signals. As a workaround, you could remove "MediaKeysHandler" from line 303 in the script so that it only handles notifications and Telepathy.

@kav2k

This comment has been minimized.

Show comment
Hide comment
@kav2k

kav2k Oct 21, 2013

I'll investigate it further. For now this can be closed, I think.

kav2k commented Oct 21, 2013

I'll investigate it further. For now this can be closed, I think.

@kav2k kav2k closed this Oct 21, 2013

@nullEuro

This comment has been minimized.

Show comment
Hide comment
@nullEuro

nullEuro Oct 21, 2013

Contributor

I do not have spotify-gnome installed and can use the media keys with Spotify on Ubuntu. Your Unity theory may be correct.

Contributor

nullEuro commented Oct 21, 2013

I do not have spotify-gnome installed and can use the media keys with Spotify on Ubuntu. Your Unity theory may be correct.

@kav2k

This comment has been minimized.

Show comment
Hide comment
@kav2k

kav2k Oct 21, 2013

In any case this happened relatively recently, a week ago or so.

kav2k commented Oct 21, 2013

In any case this happened relatively recently, a week ago or so.

@kav2k

This comment has been minimized.

Show comment
Hide comment
@kav2k

kav2k Oct 21, 2013

Actually, Spotify changelog for 0.9.4 explicitly mentions: "Linux only: Media key support in Gnome"

kav2k commented Oct 21, 2013

Actually, Spotify changelog for 0.9.4 explicitly mentions: "Linux only: Media key support in Gnome"

@DavidCDean

This comment has been minimized.

Show comment
Hide comment
@DavidCDean

DavidCDean Oct 21, 2013

Maybe just a cli arg for compatibility reasons, since you've already written the functionality in. I've had good luck with the getopt module.

DavidCDean commented Oct 21, 2013

Maybe just a cli arg for compatibility reasons, since you've already written the functionality in. I've had good luck with the getopt module.

@jreese

This comment has been minimized.

Show comment
Hide comment
@jreese

jreese Oct 24, 2013

Owner

FWIW, I added the --no-keys argument in f767c4a, and at the same time I was able to replicate the ability of Spotify to respond to Gnome's media keys without spotify-gnome running. However, I suspect the reason that I don't suffer from the originally-reported issue is due to a difference in the way Gnome handles these dbus events compared to Unity; spotify-gnome should be catching the dbus events and preventing them from propogating further, but perhaps Unity sends them in such a way that the propogation continues on to Spotify as well.

In any case, now that Spotify supports the media keys directly, --no-keys should provide a temporary fix. I will probably drop the media key support altogether in a month or so once the latest version of Spotify has had a better chance to proliferate. I'll reopen this task until that has been completed.

Owner

jreese commented Oct 24, 2013

FWIW, I added the --no-keys argument in f767c4a, and at the same time I was able to replicate the ability of Spotify to respond to Gnome's media keys without spotify-gnome running. However, I suspect the reason that I don't suffer from the originally-reported issue is due to a difference in the way Gnome handles these dbus events compared to Unity; spotify-gnome should be catching the dbus events and preventing them from propogating further, but perhaps Unity sends them in such a way that the propogation continues on to Spotify as well.

In any case, now that Spotify supports the media keys directly, --no-keys should provide a temporary fix. I will probably drop the media key support altogether in a month or so once the latest version of Spotify has had a better chance to proliferate. I'll reopen this task until that has been completed.

@nougad

This comment has been minimized.

Show comment
Hide comment
@nougad

nougad Nov 26, 2013

Spotify registers correctly to gnome settings daemon using GrabMediaPlayerKeys() but it seams it doesn't respond to the MediaPlayerKeyPressed signal. But it responds to the media buttons if the window is focused (but this has nothing to do with the settings daemon). Maybe this behavior leads to confusion.

My problem is I'm not running gnome-settings-daemon because I'm on xfce. I'm using mkd.py (https://code.google.com/p/mediakeys-daemon/downloads/detail?name=mkd.py). This sends a key press to all registered media applications. If I'm using spotify + spotify-gnome every key press gets two times to spotify because both registering as a application. But if I'm running only spotify no one responds to the key press because spotify seams to ignore the signal.

I'm not sure how the gnome-settings-daemon is distributing the signal to the registered applications. Maybe only the last application gets the signal. But if not this might be a problem as well on gnome. If gnome handles this correct then please ignore my edge case with xfce.

There is a fork of mkd (https://github.com/nandhp/mediakeys-daemon) which handles it in the gnome way - so indeed only the last app gets the keys. Sry for the mistake.

But then the gnome-spotify should check the first parameter (application name) to be "Spotify". For example the use case: start spotify, start totem, play on totem, press pause button -> should pause totem and not start spotify as well. The first parameter of the MediaPlayerKeyPressed should be 'Totem' and the second 'Play' so spotify-gnome should ignore this.

Another use case that fails is: open spotify, open totem, go back to spotify and press play. Now Spotify should be the last application and should get the key press. But the wrapper doesn't call GrabMediaPlayerKeys again. I use for this:

xdotool search --sync --classname Spotify behave %@ focus exec --sync dbus-send --session --type=method_call --dest=org.gnome.SettingsDaemon /org/gnome/SettingsDaemon/MediaKeys org.gnome.SettingsDaemon.MediaKeys.GrabMediaPlayerKeys string:"Spotify" uint32:0

nougad commented Nov 26, 2013

Spotify registers correctly to gnome settings daemon using GrabMediaPlayerKeys() but it seams it doesn't respond to the MediaPlayerKeyPressed signal. But it responds to the media buttons if the window is focused (but this has nothing to do with the settings daemon). Maybe this behavior leads to confusion.

My problem is I'm not running gnome-settings-daemon because I'm on xfce. I'm using mkd.py (https://code.google.com/p/mediakeys-daemon/downloads/detail?name=mkd.py). This sends a key press to all registered media applications. If I'm using spotify + spotify-gnome every key press gets two times to spotify because both registering as a application. But if I'm running only spotify no one responds to the key press because spotify seams to ignore the signal.

I'm not sure how the gnome-settings-daemon is distributing the signal to the registered applications. Maybe only the last application gets the signal. But if not this might be a problem as well on gnome. If gnome handles this correct then please ignore my edge case with xfce.

There is a fork of mkd (https://github.com/nandhp/mediakeys-daemon) which handles it in the gnome way - so indeed only the last app gets the keys. Sry for the mistake.

But then the gnome-spotify should check the first parameter (application name) to be "Spotify". For example the use case: start spotify, start totem, play on totem, press pause button -> should pause totem and not start spotify as well. The first parameter of the MediaPlayerKeyPressed should be 'Totem' and the second 'Play' so spotify-gnome should ignore this.

Another use case that fails is: open spotify, open totem, go back to spotify and press play. Now Spotify should be the last application and should get the key press. But the wrapper doesn't call GrabMediaPlayerKeys again. I use for this:

xdotool search --sync --classname Spotify behave %@ focus exec --sync dbus-send --session --type=method_call --dest=org.gnome.SettingsDaemon /org/gnome/SettingsDaemon/MediaKeys org.gnome.SettingsDaemon.MediaKeys.GrabMediaPlayerKeys string:"Spotify" uint32:0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment