mirror of
https://github.com/Rigellute/spotify-tui.git
synced 2026-04-26 08:05:57 +03:00
[GH-ISSUE #147] Mapping keyboard forward/back/play buttons? #80
Labels
No labels
bug
enhancement
good first issue
help wanted
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotify-tui#80
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
@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
spotifydshould handle the media keys.However, if it is easy for us to implement in
spotify-tuithan we could do it.@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.
@sputnick1124 commented on GitHub (Nov 16, 2019):
I'm inclined to agree with @LU15W1R7H, but this is more complicated than other normal key input.
spotifyddoes 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.
@Rigellute commented on GitHub (Nov 18, 2019):
If
spotifydsupports this (albeit experimental), I don't thinkspotify-tuishould also attempt to implement it.Given that the official client handles the media keys and
spotifydsupports them, I feel it would complicate things greatly forspotify-tuito also support them.@dzfranklin commented on GitHub (Dec 6, 2019):
What if
sptexposed 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.
spotifyddoesn'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).
@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.@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) nPrev song:
xdotool key --window $(xdotool search --classname spotify-tui) pPause/play:
xdotool key --window $(xdotool search --classname spotify-tui) spaceSpotify-tui controls spotify on my phone (bluetooth headset and no usb dongle of bluetooth) so this works great.
@Rigellute commented on GitHub (Feb 12, 2020):
Very cool @xanderificnl! Thank you!
@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.
@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)@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:
@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.
@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. :)
@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 :)
@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).
@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
@ConstantMan commented on GitHub (Apr 14, 2021):
Hey I'm trying to use xdotoool with these commands but i can't figure out why it doesn't work any ideas ?
@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
sptand usespt pb --next.