[Proposal] playerctl module

[Joey Holtzman]

Is your feature request related to a problem? Please describe.
There currently is no general media player module. Py3status has cmus and player_control, but playerctl would provide a more general solution.

Your py3status version
3.5.0

Describe the solution you'd like
A playerctl module, similar to cmus, that allows you to control media players.

Describe alternatives you've considered
Extending a current module could work, but it might be better to create a new one using playerctl.

Additional context
I have created my own minimum working version of a playerctl module (the code is very similar to cmus). I could definitely create a PR for it once I make it more accessible to users. This module would not replace the cmus module because the cmus module provides a lot more information for cmus specifically. However, it could replace the player_control module (or potentially other media modules).

This was mentioned previously in #1099 and #1797, but no further actions were taken.

[lasers]

Make a PR when you're ready. 👍

[Joey Holtzman]

Hey @lasers, I have a few different approaches to this, each with their pros and cons, and I wanted to get your opinion on the best approach for py3status.

1. Get the metadata of the most recently active player. Then, parse it and display the information based on self.format -- this would be very close to how the cmus module works. Two commands need to be executed (one for the metadata and one for the status)

• A disadvantage of this is that not all desired metadata is actually output by playerctl (ex: position in the song)

2. Use the --format option that is native to playerctl. The user would specify their format for each player (in a dictionary format: {"player1": "format1", "player2": "format2"}. This makes the format more customizable for each player because different data is available for each player

• An advantage of this is users can directly use the formatting functions available from playerctl. Additionally, more data about the player is available (such as position)
• A disadvantage of this is that it needs 3 commands to execute per cycle (one to get the currently active player so we know what format to use, another to get the metadata, and the last to get the status)

3. Use the Playerctl Python bindings that are a part of PyGObject. This would be the most customizable and robust way as no external commands need to be executed

• However, a disadvantage is that the module will need to run a never-ending loop in order to process the event handlers that are necessary for this implementation. This can either be done with asyncio or threading in order to not block py3status from updating the module. I'm hesitant on this, though, because it is unclear to me if running in another thread can negatively affect py3status.

I'd love to hear if you have any other suggestions. Thanks!

[lasers]

Use the Playerctl Python bindings that are a part of PyGObject. This would be the most customizable and robust way as no external commands need to be executed

My opinion is to try for 3) first, https://github.com/altdesktop/playerctl/blob/master/examples/player-manager.py, to just handle all possible players including new ones in future.

• Make config format = '{format_player}'.
• Make config something like format_player = '{name} {title} {track} etc' for all players. Unavailable placeholders in some players can always be hidden in brackets (ie [{position) if necessary.
• All found instances would be exposed / connected.
• I think users wouldn't care about per-player settings and I imagine if you want to do per-player format, then you will have to make default player format too... which could be a little messy / repetitive.

The hard part is also to make play/pause/stop buttons work in all instances too. #Ignoreme.