Hide the extension's panel when nothing is playing

[vixalien]

Currently, a small blob appears when nothing is playing. Would be cool to hide the extension completely when nothing is playing... like the Removable media extension.

[Moon-0xff]

First of all, were you hovering the pointer over the blob in that screenshot?

[vixalien]

yes I was.

I removed all padding in the extension settings so that the "blob" is as small as possible. And when there are more panels, it creates a gap between those items.

[Moon-0xff]

Yes, hiding that blob is something I've been wanting to do since the release of GNOME 40 but never tried!

I will keep it on the top of the imaginary to-do list.

[vixalien]

haha take your time...

[Batwam]

Gnome 40 introduced sizable padding which has been driving me nuts (culminating in #16) but as long as the extension is not between other icons, it's not noticeable.

I guess we are already removing the container and putting it back in when relocating the extension so we already have the building blocks within _updateTrayPosition()? Just need to remove this.container if the label is blank and trigger _updateTrayPosition() when the text comes back in I suppose.

One thing to consider however is that having the container there allows to access the menu to select another source, activate play/pause and/or access the Settings so hiding it could introduce some practical limitations, especially for people who switch source manually?

[nkcong206]

I see in Aylur's Widgets extension they can do it but it makes lag. I hope you can take a look at it.

[Moon-0xff]

Yes, It uses the same functions I was thinking of, PanelMenu.Button.hide and .show.

I think the lag comes from spawning the panel media buttons, we have the same problem in #39

[Batwam]

for what it's worth, i found out that if we include this.set_style("border: 0px;"); within _init(), the panel-button won't show any highlight when the mouse is over it. Controls (scroll, right click, ....) still work though.

This means that when the label is in "hide when paused" mode, there is virtually no way to tell it's there. Right click will still work so the menu can still be accessed. All in all, it makes the extension integrated like info in the panel rather than a button but perhaps makes it less obvious that there are functionalities accessible on click.

Alternatively, it would probably be possible to set the border to 0 when pause and then back to 1px when the label is showing some text.

[vixalien]

I think instead of that, straight up hiding/showing the panel icon would be better if possible.

[Batwam]

Yeah, it's a bit of a hack. I just wanted to put it out there as I stumbled upon this behaviour while working on another PR and there seemed to be some lags discussed above when using show/hide.

[abisammy]

Yeah, it's a bit of a hack. I just wanted to put it out there as I stumbled upon this behaviour while working on another PR and there seemed to be some lags discussed above when using show/hide.

Just tried a commit in my test branch (0fa1848) which uses the event based system in #60 (note this hasn't been implemented there yet), and there doesnt seem to be any issues with lag...
Could it be that the old refreshing system was causing the lag with show and hide?

Also I think the solution could be refactored to make the code more efficient.

[Moon-0xff]

Hide the extension's panel when nothing is playing

Added in #69 by @abisammy on the refreshless-dev branch.

It will take a while until is merged to main and a bit more to be included with an update.

Addressing the lag concerns, it looks like the label is noticeable slower to appear on the tray, but as the extension is now refreshless and uncoupled from the main gnome-shell thread it shouldn't create any lag.

edit: It's not noticeable slower except with shortwave, that's expected.

[Moon-0xff]

The current version of the extension (v18) hides the extension when there's no (non-filtered) player available.

Not quite "when nothing is playing" but I surely think it's better than always having the widget on the panel.

[Batwam]

issue closed?

[vixalien]

can confirm the issue still exists

[Batwam]

Is it still showing when you don't have any players open? Do you have any player listed in the menu when you click? It should go away when there is no active player.

btw, is the extension working well with muzika? I haven't tried it yet but I'm hearing good things about it.

[vixalien]

Is it still showing when you don't have any players open?

It seems the extension hides the icon when nothing is playing. However when I play music and pause, the panel is hidden (because of the "Hide when paused") but I can still hover over the icon like in the case above.

btw, is the extension working well with muzika?

yes. the extension works well with muzika :) thanks for working on this extension.

I haven't tried it yet but I'm hearing good things about it.

hmm I didn't know it was that famous. thank you :)

[Moon-0xff]

I added a rule to also hide the widget if there's just one player and isn't active, then I realized it would prevent the use of the player controls.

Going further than that, like hiding the widget when there's multiple players but no active one would start to conflict with the ability of selecting between sources, another tradeoff.

I think the first should be added to the 'Hide when paused' option, but then again it conflicts with some functionality.

[Batwam]

If we want to implement this fully, I'm thinking that the best solution might be to have separate options altogether:

• hide label when paused (blank label but still able to access controls)
• hide extension when nothing is playing (hides extension)

I would personally use the first one but not the second one as I still want to be able to click to play/pause, open app, access menu,... and would recommend to have these settings turned off as default to avoid confusion with the label/extension disappearing on users.

Hiding the label only makes sense if Hiding the extension is off obviously so these two options would need to be linked.

One case to consider is with users manually setting the active player. There could be a situation there the selected player is paused but a second source is playing. Do we hide or show the extension in this case? If we hide it, it becomes impossible to switch back to the active one...

[Moon-0xff]

I agree that it's better to leave the choice to the user, but how to clearly present such a choice to the user is challenging.

And it will have to use the placeholder button logic or similar to prevent a selection soft-lock.

the blob (and the placeholder button) will inevitably need to appear sometimes.
At that point is the setting even meaningful? It will not prevent the blob from appearing, it will just make it less likely to appear.

[Batwam]

Rather than a double switch, we could also have a dropdown for "Hide when paused" to select between off/hide text/hide extension.

But again, do we want to hide the extension when the "active" source is stopped but there is another one potentially playing?

@vixalien since you don't consider that the extension currently does what you want, what is the scenario where you see the blob but shouldn't? Is it because music is playing in another source?

[vixalien]

it should just be completely hidden. I don't want the blob at all

[Batwam]

Yes but in which situation do you see this blob? Currently, if you have only one source active and it's not playing music, the blob should be hidden. Are you seeing it because you are:

• playing music using a different app than the "active" one
• having an issue with a web browser being recognise as a source and therefore preventing the blob from hiding?
• different scenario, which one?

[vixalien]

The blob appears when I play music and pause for a bit. the label disappears but there is still empty space in the panel.

[Batwam]

I'm trying to establish if this is a bug as this blob shouldn't appear unless you have multiple mpris sources opened. When this happens, what do you get if you run dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep mpris?

[Moon-0xff]

I'm trying to establish if this is a bug as this blob shouldn't appear unless you have multiple mpris sources opened

This is not a bug, the blob is hidden only if there's no non-filtered players available. Checkout 8aecf95.

[Moon-0xff]

I'm trying to establish if this is a bug as this blob shouldn't appear unless you have multiple mpris sources opened.

I added this behaviour (didn't commit/push anything) and realized it conflicts with the player controls.

I think this should be added to the extension but I don't think it should be forced to the user.
At the same time, I don't think this change should be presented as an standalone? option either, it's too small of a change.

Going further than that wouldn't achieve too much because the ability of selecting between sources needs to be preserved.

I already mentioned all of this, more details above.

[Batwam]

That's the point I am trying to make. I have the feeling that there is another mpris source preventing it from being hidden. I think that the solution in this case is for @vixalien to filter the source which is causing the blob not to disappear. The only other explanation would be that it's not hiding when it normally should which is unlikely.

[vixalien]

Here is a screen record to prove that I only have one source. The blob is there without the playing title controls when I pause the playback.

Screencast.from.2023-10-26.23-06-11.webm

[Batwam]

Apologies as I was mistaken. I misread and thought that the extension was meant to be hidden when there was only 1 player and it's paused. As it turns out, it only hides if there are no players listed.

I am leaning towards a solution where we have a separate option called "Hide extension when Paused" underneath the existing one. Either that or we can have a drop down with "When Paused" and then a drop down to select between:

• Show label
• Hide label
• Hide extension

The drop down solution kind of makes sense and it wouldn't be logical to hide the extension without hiding the label...

[Moon-0xff]

I lean towards a separate option too. Combining the options would require an explanation and I don't imagine how we can word it in a non-confusing way.

[Batwam]

see PR #87 , let me know if that does what you want as I had to make some assumptions.

[Moon-0xff]

Yes, assumptions. Is not a good thing to say, ultimately all should rest with the user but giving choice of such an inconsequential thing isn't worth it.

I might push something on the next few days to address this, but it will most likely not make it to an update. I'm too undecided about this.

[Moon-0xff]

I'm working (slowly I should add) on a solution for this.

At last I decided to implement similar behaviour or maybe the same as in #87. I left room for a less aggressive solution, or an even more aggressive one. I'm also refactoring code.

Writing this just for info, I don't know when I'll have something to show.