[GH-ISSUE #147] Mapping keyboard forward/back/play buttons? #80

Open
opened 2026-02-28 14:46:51 +03:00 by kerem · 17 comments
Owner

Originally created by @wadewilliams on GitHub (Nov 12, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/147

My keyboard has buttons for previous/next track and play/pause.

These are super nice because I don't have to change context back to the spotify app to pause, etc.

Must have feature for me. Thank you for this!

edit: The buttons work if I have the full spotify application running, but using spotifyd and spotify-tui in tandem doesnt work. Please let me know if this issue is better addressed in spotifyd repo.

Originally created by @wadewilliams on GitHub (Nov 12, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/147 My keyboard has buttons for previous/next track and play/pause. These are super nice because I don't have to change context back to the spotify app to pause, etc. Must have feature for me. Thank you for this! edit: The buttons work if I have the full spotify application running, but using spotifyd and spotify-tui in tandem doesnt work. Please let me know if this issue is better addressed in spotifyd repo.
Author
Owner

@Rigellute commented on GitHub (Nov 13, 2019):

I also tend to have the full spotify client open so the media keys work. My intuition is that spotifyd should handle the media keys.

However, if it is easy for us to implement in spotify-tui than we could do it.

<!-- gh-comment-id:553296992 --> @Rigellute commented on GitHub (Nov 13, 2019): I also tend to have the full spotify client open so the media keys work. My intuition is that `spotifyd` should handle the media keys. However, if it is easy for us to implement in `spotify-tui` than we could do it.
Author
Owner

@luiswirth commented on GitHub (Nov 13, 2019):

I think spotify-tui should be responsible for handling all key inputs, including the media keys.
Spotifyd should remain just a music daemon for playing and nothing more.

<!-- gh-comment-id:553384088 --> @luiswirth commented on GitHub (Nov 13, 2019): I think spotify-tui should be responsible for handling **all** key inputs, including the media keys. Spotifyd should remain just a music daemon for playing and nothing more.
Author
Owner

@sputnick1124 commented on GitHub (Nov 16, 2019):

I'm inclined to agree with @LU15W1R7H, but this is more complicated than other normal key input. spotifyd does support this, apparently, but I have never gotten it to function correctly.

I know of no other way to handle the media keys in Linux than using the dbus/mpris method. While certainly more complicated than the rest of the app's key handling, I think adding support for mpris wouldn't be too terribly cumbersome.

If anybody knows of other ways to handle media keys, I'm all ears. Also, this would, to my knowledge, be a Linux-only (maybe Mac?) feature.

<!-- gh-comment-id:554666511 --> @sputnick1124 commented on GitHub (Nov 16, 2019): I'm inclined to agree with @LU15W1R7H, but this is more complicated than other normal key input. `spotifyd` [does support this](https://github.com/Spotifyd/spotifyd#media-controls), apparently, but I have never gotten it to function correctly. I know of no other way to handle the media keys in Linux than using the dbus/mpris method. While certainly more complicated than the rest of the app's key handling, I think adding support for mpris wouldn't be too terribly cumbersome. If anybody knows of other ways to handle media keys, I'm all ears. Also, this would, to my knowledge, be a Linux-only (maybe Mac?) feature.
Author
Owner

@Rigellute commented on GitHub (Nov 18, 2019):

If spotifyd supports this (albeit experimental), I don't think spotify-tui should also attempt to implement it.

Given that the official client handles the media keys and spotifyd supports them, I feel it would complicate things greatly for spotify-tui to also support them.

<!-- gh-comment-id:554945248 --> @Rigellute commented on GitHub (Nov 18, 2019): If `spotifyd` supports this (albeit experimental), I don't think `spotify-tui` should also attempt to implement it. Given that the official client handles the media keys and `spotifyd` supports them, I feel it would complicate things greatly for `spotify-tui` to also support them.
Author
Owner

@dzfranklin commented on GitHub (Dec 6, 2019):

What if spt exposed the command line arguments --next, --prev, --toggle-paused, --volume-up, and --volume-down? They would ideally error if spotify-tui wasn't running, and if spotify-tui was running would have the same result as pressing the shortcuts in the TUI.

This would allow users to map their keys however worked best for them. Cursory Google search turn up relatively easy ways to bind a keyboard shortcut to a command on macOS, GNOME, and KDE. I use i3 and would be able to do this with a simple config file edit.

This would slightly decrease ease-of-use, but spotify-tui already requires equally complicated steps to authenticate. It would also let users have more control than the default Spotify client by allowing them to manipulate the Spotify volume (My use case: I listen to Spotify while playing videos, and sometimes the videos are quieter. I want to increase the video volume while decreasing the Spotify volume, so I can hear the video decently).

I don't think this would cause complications by duplicating functionality, at least in the sense that users wouldn't run into errors from both programs attempting to respond. spotifyd doesn't attempt to handle the media keys, it provides support for users to configure other software to handle the media keys (with difficulty).

I don't know how hard this would be to implement. I'm learning Rust right now, would you accept a PR? (I'm not certain I'd have the time to do it promptly).

<!-- gh-comment-id:562402314 --> @dzfranklin commented on GitHub (Dec 6, 2019): What if `spt` exposed the command line arguments `--next`, `--prev`, `--toggle-paused`, `--volume-up`, and `--volume-down`? They would ideally error if spotify-tui wasn't running, and if spotify-tui was running would have the same result as pressing the shortcuts in the TUI. This would allow users to map their keys however worked best for them. Cursory Google search turn up relatively easy ways to bind a keyboard shortcut to a command on [macOS](https://apple.stackexchange.com/questions/24063/create-global-shortcut-to-run-command-line-applications), [GNOME](https://docs.fedoraproject.org/en-US/quick-docs/proc_setting-key-shortcut/), and [KDE](https://www.maketecheasier.com/configure-custom-shortcuts-in-kde/). I use i3 and would be able to do this with a simple config file edit. This would slightly decrease ease-of-use, but spotify-tui already requires equally complicated steps to authenticate. It would also let users have more control than the default Spotify client by allowing them to manipulate the Spotify volume (My use case: I listen to Spotify while playing videos, and sometimes the videos are quieter. I want to increase the video volume while decreasing the Spotify volume, so I can hear the video decently). I don't think this would cause complications by duplicating functionality, at least in the sense that users wouldn't run into errors from both programs attempting to respond. `spotifyd` doesn't attempt to handle the media keys, it provides support for users to configure other software to handle the media keys (with difficulty). I don't know how hard this would be to implement. I'm learning Rust right now, would you accept a PR? (I'm not certain I'd have the time to do it promptly).
Author
Owner

@Rigellute commented on GitHub (Dec 23, 2019):

@danielzfranklin interesting suggestion. This sounds doable, though somewhat tricky.

Feel free to take a stab at a PR.

However, I still think that this feature is better handled by spotifyd.

<!-- gh-comment-id:568430349 --> @Rigellute commented on GitHub (Dec 23, 2019): @danielzfranklin interesting suggestion. This sounds doable, though somewhat tricky. Feel free to take a stab at a PR. However, I still think that this feature is better handled by `spotifyd`.
Author
Owner

@ghost commented on GitHub (Feb 12, 2020):

It's also possible to use xdotool to send keys to spotify-tui without much hassle.

Start spotify-tui with a known window classname:
urxvt -name spotify-tui -e "spt"

Send commands to the window:
Next song: xdotool key --window $(xdotool search --classname spotify-tui) n
Prev song: xdotool key --window $(xdotool search --classname spotify-tui) p
Pause/play: xdotool key --window $(xdotool search --classname spotify-tui) space

Spotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great.

<!-- gh-comment-id:584973799 --> @ghost commented on GitHub (Feb 12, 2020): It's also possible to use xdotool to send keys to spotify-tui without much hassle. Start spotify-tui with a known window classname: `urxvt -name spotify-tui -e "spt"` Send commands to the window: Next song: `xdotool key --window $(xdotool search --classname spotify-tui) n` Prev song: `xdotool key --window $(xdotool search --classname spotify-tui) p` Pause/play: `xdotool key --window $(xdotool search --classname spotify-tui) space` Spotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great.
Author
Owner

@Rigellute commented on GitHub (Feb 12, 2020):

Very cool @xanderificnl! Thank you!

<!-- gh-comment-id:585163299 --> @Rigellute commented on GitHub (Feb 12, 2020): Very cool @xanderificnl! Thank you!
Author
Owner

@freundTech commented on GitHub (Feb 26, 2020):

Despite spotify and spotifyd already supporting mpris2 I think that having support for it in spotify-tui would be a good idea, as it would allow controlling remote spotify instances with mpris.
In my case I have librespot (The library spotifyd is based on) running on my raspberry pi and use spotify-tui on my PC to control it.

Another alternative would be having a different spotify connect client, that only handles mpris.
That's how I used to do it with mpd: Run the mpd daemon, which doesn't support mpris, a client without mpris and another client that only offered mpris.

<!-- gh-comment-id:591528365 --> @freundTech commented on GitHub (Feb 26, 2020): Despite spotify and spotifyd already supporting mpris2 I think that having support for it in spotify-tui would be a good idea, as it would allow controlling remote spotify instances with mpris. In my case I have librespot (The library spotifyd is based on) running on my raspberry pi and use spotify-tui on my PC to control it. Another alternative would be having a different spotify connect client, that only handles mpris. That's how I used to do it with mpd: Run the mpd daemon, which doesn't support mpris, a client without mpris and another client that only offered mpris.
Author
Owner

@freundTech commented on GitHub (Feb 29, 2020):

Ok. I quickly hacked a standalone MPRIS2 interface together in case anyone is interested.
It's in python (I don't know enough rust) and still has a few bugs, but it's already more complete than the MPRIS2 interface built into the spotify linux client: https://github.com/freundTech/SpotPRIS2
You can install it using pip (pip install spotpris2) or if you are on arch from the aur (yay -S python-spotpris2)

<!-- gh-comment-id:593005923 --> @freundTech commented on GitHub (Feb 29, 2020): Ok. I quickly hacked a standalone MPRIS2 interface together in case anyone is interested. It's in python (I don't know enough rust) and still has a few bugs, but it's already more complete than the MPRIS2 interface built into the spotify linux client: https://github.com/freundTech/SpotPRIS2 You can install it using pip (```pip install spotpris2```) or if you are on arch from the aur (```yay -S python-spotpris2```)
Author
Owner

@AndydeCleyre commented on GitHub (Apr 5, 2020):

Adding, since I don't see it mentioned, that playerctl is an excellent utility that may be a good solution for some folks here.

For example, I have my DE set global keyboard shortcuts for the following commands:

playerctl -p spotify,ncspot,mopidy,spotifyd next
playerctl -p spotify,ncspot,mopidy,spotifyd play-pause

@danielzfranklin note that it also supports volume changes.

But I don't think it would help for those looking to control remote spotify clients, @freundTech . I haven't personally tested other tools that might help with that, but know of baton.

<!-- gh-comment-id:609449507 --> @AndydeCleyre commented on GitHub (Apr 5, 2020): Adding, since I don't see it mentioned, that [playerctl](https://github.com/altdesktop/playerctl) is an excellent utility that may be a good solution for some folks here. For example, I have my DE set global keyboard shortcuts for the following commands: ```bash playerctl -p spotify,ncspot,mopidy,spotifyd next playerctl -p spotify,ncspot,mopidy,spotifyd play-pause ``` @danielzfranklin note that it also supports volume changes. But I don't think it would help for those looking to control remote spotify clients, @freundTech . I haven't personally tested other tools that might help with that, but know of [baton](https://github.com/joshuathompson/baton).
Author
Owner

@jvinet commented on GitHub (May 12, 2020):

If spotify-tui supported MPRIS directly, then I could use the media buttons on my laptop to control music playing from another Spotify device. spotifyd doesn't do this.

It's a minor use case, but super useful. :)

<!-- gh-comment-id:627034224 --> @jvinet commented on GitHub (May 12, 2020): If spotify-tui supported MPRIS directly, then I could use the media buttons on my laptop to control music playing from another Spotify device. spotifyd doesn't do this. It's a minor use case, but super useful. :)
Author
Owner

@fbrinker commented on GitHub (May 16, 2020):

+1 :)

I mostly listen remotely with Alexa connected to the Speakers and right now i don't have any option to control the media player with my keyboard shortcuts (and playerctl) :)

Spotifyd works to get the metadata for my Polybar, but doesn't let me control remote devices.

Besides play, pause, stop, next, ... would volume keybindings be nice too

@ghost thanks for the workaround for the moment :)

<!-- gh-comment-id:629699155 --> @fbrinker commented on GitHub (May 16, 2020): +1 :) I mostly listen remotely with Alexa connected to the Speakers and right now i don't have any option to control the media player with my keyboard shortcuts (and playerctl) :) Spotifyd works to get the metadata for my Polybar, but doesn't let me control remote devices. Besides play, pause, stop, next, ... would volume keybindings be nice too @ghost thanks for the workaround for the moment :)
Author
Owner

@freundTech commented on GitHub (May 17, 2020):

@jvinet @fbrinker https://github.com/freundTech/SpotPRIS2 let's you control Spotify, even remote instances, using mpris2 (and therefor using playerctl).

<!-- gh-comment-id:629774988 --> @freundTech commented on GitHub (May 17, 2020): @jvinet @fbrinker https://github.com/freundTech/SpotPRIS2 let's you control Spotify, even remote instances, using mpris2 (and therefor using playerctl).
Author
Owner

@fbrinker commented on GitHub (May 17, 2020):

@freundTech nice, that works very well, using it with the --auto flag :)
Will use it for now, thank you. I would prefer an all in one solution, but an interesting project 👍

Edit: Okay spotpris is awesome, so i can use it to fetch the correct metadata and playing status for my polybar and remote control every spotify device now without any pgrep switches

<!-- gh-comment-id:629779488 --> @fbrinker commented on GitHub (May 17, 2020): @freundTech nice, that works very well, using it with the --auto flag :) Will use it for now, thank you. I would prefer an all in one solution, but an interesting project :+1: Edit: Okay spotpris is awesome, so i can use it to fetch the correct metadata and playing status for my polybar and remote control every spotify device now without any pgrep switches
Author
Owner

@ConstantMan commented on GitHub (Apr 14, 2021):

It's also possible to use xdotool to send keys to spotify-tui without much hassle.

Start spotify-tui with a known window classname:
urxvt -name spotify-tui -e "spt"

Send commands to the window:
Next song: xdotool key --window $(xdotool search --classname spotify-tui) n
Prev song: xdotool key --window $(xdotool search --classname spotify-tui) p
Pause/play: xdotool key --window $(xdotool search --classname spotify-tui) space

Spotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great.

Hey I'm trying to use xdotoool with these commands but i can't figure out why it doesn't work any ideas ?

<!-- gh-comment-id:819147502 --> @ConstantMan commented on GitHub (Apr 14, 2021): > It's also possible to use xdotool to send keys to spotify-tui without much hassle. > > Start spotify-tui with a known window classname: > `urxvt -name spotify-tui -e "spt"` > > Send commands to the window: > Next song: `xdotool key --window $(xdotool search --classname spotify-tui) n` > Prev song: `xdotool key --window $(xdotool search --classname spotify-tui) p` > Pause/play: `xdotool key --window $(xdotool search --classname spotify-tui) space` > > Spotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great. Hey I'm trying to use xdotoool with these commands but i can't figure out why it doesn't work any ideas ?
Author
Owner

@tonglil commented on GitHub (Aug 23, 2022):

I'm considering hacking on https://github.com/Sinono3/souvlaki as a standalone project to learn Rust so it can pull info from spt and use spt pb --next.

<!-- gh-comment-id:1223542558 --> @tonglil commented on GitHub (Aug 23, 2022): I'm considering hacking on https://github.com/Sinono3/souvlaki as a standalone project to learn Rust so it can pull info from `spt` and use `spt pb --next`.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/spotify-tui#80
No description provided.