Skip to content
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

playerctl module: hide non-can-play players and use chrome and chromium as default value. #2256

Merged
merged 2 commits into from
Oct 24, 2024

Conversation

valdur55
Copy link
Contributor

Proposes improvement for issue #2255.

@valdur55 valdur55 force-pushed the playerctl-hide_non_canplay branch from a80ebcf to 167cb32 Compare August 27, 2024 17:25
@valdur55 valdur55 changed the title playerctl module: hide non-can-play and players use chrome and chromium as default value. playerctl module: hide non-can-play players and use chrome and chromium as default value. Aug 27, 2024
@valdur55 valdur55 force-pushed the playerctl-hide_non_canplay branch from 167cb32 to d75ffb7 Compare August 27, 2024 19:20
@@ -273,6 +276,12 @@ def playerctl(self):
players = []
cached_until = self.py3.CACHE_FOREVER
for player in tracked_players:
if (
not player.props.can_play
Copy link
Contributor

@lasers lasers Aug 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without digging in, Is not player.props.can_play alone enough without player_hide_non_canplay config.... This seems like an mpris issue on chrome/chromium side.

Do chrome/chromium change this flag when it's playing/not playing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually there are other chromium based browsers like brave which has same bug. Chromium issue tracker has already bug in their system: https://issues.chromium.org/issues/40703847
Even the issue is from older raport states same issue: JasonLG1979/gnome-shell-extension-mpris-indicator-button#10

Added some pictures about different "can" properties:

State when chromium is playing media
image

State when chromium media is paused:
image

State when chromium mpris is idle state:
image

VLC is opened but no media opened (just opened vlc, no media selected):
image

VLC is opened, media loaded and stopped playing media.
image

I don't wan't to blindly hide all players with can_play == false state because I prefer to see VLC media player on statusbar just after I opened it as empty player.

It littlebit seems like hide_non_can_play is too technical so even we can simplify it to level: hide media players stopped state and user provides list on media players which he want to hide.

I searched some chromium source code and found out where this all "can" properties false comes. I suspect that line is this: https://source.chromium.org/chromium/chromium/src/+/main:components/system_media_controls/linux/system_media_controls_linux.cc;l=288

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have been out of scene with py3status. Just sharing thoughts.

I think it doesn't benefit users to display empty players. If anything, this is maybe something that should be added in first place to ensure better quality control/behavior.

I do think hide_non_can_play config is too specific that partially addresses chromium-based players and not that general... I would like an approach that that users can allow/deny (all) can_xxx_xxx configs (either by a dict config or new placeholders). New placeholders that exposes boolean like this... is maybe hard for users to come up with a new format_player that excludes those players... Dict may be be easier.

I prefer to see VLC media player on statusbar just after I opened it as empty player.

It should be easier to just ignore players that doesn't have can_play flag true because of things like... You saying you don't like this empty-player thing on chrome/chromium #2255 but are okay with this on vlc... I think it would make more sense to avoid all empty-players in first place... to keep it simple.

This approach also may omit the need for adding |{player} at end of format_player config too.

Try it for a while. See if this small but simple tweak works quite well.

@lasers
Copy link
Contributor

lasers commented Sep 1, 2024

Is it fixable with format_player?

# Hide on empty title, no player.
format_player = "[\?if=title [\?color=status [\?if=status=Playing > ][\?if=status=Paused \|\| ]"
format_player += "[\?if=status=Stopped .. ][[{artist}][\?soft  - ]{title}]]]"

@ultrabug
Copy link
Owner

@valdur55 do you want to follow up here before I do a release?

@valdur55
Copy link
Contributor Author

Oh no, I totaly forgot this thread.

I tested different desktop envs capabilities to handle this issue.
KDE only showed playing media players
Xfce showing m3edia players as is
Mate -no mpris status in sound menu
Gnome (https://extensions.gnome.org/extension/4928/mpris-label/) showed playing/paused media players.

Looks like winner is solution to hide paused media players, but there is one catch.
If module supports to stop media player then it is unexpected to hide stopped media player.
So looks like most pratical solution is to hide all non can_play media players.

@lasers your format_player magic didn't work for me. Player with media didn't show up.

@ultrabug ultrabug merged commit 3d8e7d8 into ultrabug:master Oct 24, 2024
7 checks passed
@ultrabug
Copy link
Owner

Thanks, will make a release soon

@valdur55
Copy link
Contributor Author

valdur55 commented Oct 24, 2024

Hey.
Actually looks like I should drop also same parameter on mpris side, so it will hide all non can_play media players by default.
I will make pr for that ASAP when I am at home.

Edit: already release. So till the next time. It isn't blocker.

Btw in conclusion. There is no new parameter, just hiding all players with can_play = False property.

@valdur55 valdur55 deleted the playerctl-hide_non_canplay branch October 24, 2024 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants