Indicator status text support

[jakejarrett]

Distro Name & Version

Ubuntu 19.04

GNOME Shell Version

3.32.0

Other Installed Extensions

N/A

Expected Behavior

Simply the defined behaviour defined in the wiki here for the old extension

Current Behavior

N/A (Not implemented)

Detailed Description

Whether this is baked in, or provided by allowing for plugins (EG/ provide a settings panel to just pull in extra plugins that implement extra behaviors like how it renders to the shell etc) is (in my opinion) up for discussion, but would be great to be able to have this functionality back. (Main thing I'm missing from the previous mpris extension)

If this task is something you'd be open to letting other people undertake, I might be able to undertake this in the near future.

[JasonLG1979]

I'm not totally against the artist and track title to the right of the icon, in fact it's one of the features I rather liked and used. The issue I have with it is that not everyone does I imagine and I want to avoid having any sort of settings at all. The main reason being that adding settings exponentially complicates an extension. You have to deal with translations, compiling the settings and writing a setting UI and what not. Not to mention feature creep and bloat. I would rather not carry a bunch of features that only a few people actually use.

If it were to be implemented even as a option it would be paired down. Basically it would be in the form of "Artist Name • Track Title" and the width of the indicator before the text was ellipsed would be the width of the menu.

I guess before I even think about adding the feature I would have to get some idea of what users think. Who likes it, who doesn't and who doesn't care. I've already tried to get a gauge of what features are important to people but didn't really get much response.

[jakejarrett]

Yeah even just a simple non-configurable option would be better than the lock of option.

There are a couple of comments on the gnome extension page asking for the feature too. (in regards to gauging interest)

You could use issues to track thumbs up / down to gauge interest in functionality or other approaches (Maybe a RFC for proposed features & see if people are interested?)

[JasonLG1979]

Changing text in the panel also presents a little bit of visual weirdness.

Our choices are:

1. Let the text be as long as it is. Which is a no go for obvious reasons.
2. Set a max width and allow the indicator's size to vary from potentially just the size of the icon (no text) to that max width where the text is ellipsed.
3. Set a static size for the width of the indicator regardless of the text.

So really we have 2 choices.

In the case of 2, the main problem is that as tracks change the indicator changes size which causes other indicators to the left to move. I'd rather not get into a shoving match with other indicators every time the text changes.

In the case of 3, a static width is certainly more consistent but it could lead to a lot dead space in the indicator. You would end up with an indicator that was guaranteed to be at least a couple if not a few hundred pixels wide.

[JasonLG1979]

This is kinda what I had in mind. The artist and track title just so happens to be about the width of the menu. But not only does the indicator change size when the text changes the actual menu moves. So if you would click the next button the menu would move and your pointer would no longer be over the next button. Moving controls is not good(edit) obviously.

[jakejarrett]

That looks good 👍 roughly what i was expecting

Would it be possible to render the same icon on the left & right align the artist/song? (might look funky, just want to check how that would feel in regards to the deadspace)

Would prefer 3 personally, provides a consistent user experience & if anyone really wanted to change that behavior, they're free to fork the project and change it 🤷‍♂️

[roizcorp]

This is kinda what I had in mind. The artist and track title just so happens to be about the width of the menu. But not only does the indicator change size when the text changes the actual menu moves. So if you would click the next button the menu would move and your pointer would no longer be over the next button. Moving controls is not obviously.

Love the idea and LOVE this song!

You pointed good points regarding text size changes and how this will affect the indicator, have you thought about scrolling text?

Can you expect how RTL languages would look like? - lower priority obviously

[JasonLG1979]

Would it be possible to render the same icon on the left & right align the artist/song?

Duplicate icons? That would just look silly,lol!!!

have you thought about scrolling text?

That doesn't really change things. Then you would just have text scrolling in a static width and you'd add a lot of UI updates. I don't think there's an easy builtin way to do scrolling text. You'd probably have to slice the string and use a timeout to update the UI.

Can you expect how RTL languages would look like? - lower priority obviously

Not that it's a lower priority, it's just that I have no idea what things are suppose to look like with RTL languages. I mean is everything backwards compared to LTR languages are somethings the same? I don't know the conventions?

[jakejarrett]

not quite, i mean more like {ICON} {space} song & title over here on the right

[JasonLG1979]

not quite, i mean more like {ICON} {space} song & title over here on the right

So you mean right justify the text?

[JasonLG1979]

Here is a working mockup. As you can see it looks pretty good as long as there is enough text to fill the space but otherwise it can have a lot of dead space.

[jakejarrett]

So you mean right justify the text?

yep lmao. forgot the wording for it my bad

The mockup looks good, yeah the deadspace is kinda bad (which is also the case on the old extension if you had a song that was long then went to short, it would sometimes have the deadspace)

[JasonLG1979]

The mockup looks good, yeah the deadspace is kinda bad (which is also the case on the old extension if you had a song that was long then went to short, it would sometimes have the deadspace)

I REALLY don't like the dead space. I think I like it worse then the indicator changing width as the text changes. But I also REALLY don't like a menu that has a good chance of moving around under your pointer every time the text changes. So both choices have really bad side effects.

I'm going to play with trying to right justify the actual menu to the indicator so that no mater where the indicator is in the panel and no matter what size it is the menu should not move relative to the right side of the indicator. I've played with the "menu alignment" but all that seems to do is set the menu alignment relative to it's parent's (the indicator) center, it doesn't take in to consideration the width of the menu unless it hits the edge of the screen.

[jakejarrett]

Yeah, seems like the API gets fairly limited in that sense then.

Might look a bit silly, but what about centered text w/ the icon (eg/ spotify icon) still on the left?

[JasonLG1979]

Yeah, seems like the API gets fairly limited in that sense then.

There is no API. Shell extensions are quite literally monkey patches. To do anything even remotely interesting you have to reach into and basically subvert running code often times relying on implementation details.

Might look a bit silly, but what about centered text w/ the icon (eg/ spotify icon) still on the left?

That would look silly,lol!!!

[JasonLG1979]

For example the default GNOME MPRIS controls are located in Main.panel.statusArea.dateMenu._messageList._mediaSection

So behind 2 underscores. Clearly an implementation detail.

To hide the default MPRIS controls you would call Main.panel.statusArea.dateMenu._messageList._mediaSection.actor.hide()

To make sure they don't show back up you have to monkey patch Main.panel.statusArea.dateMenu._messageList._mediaSection._shouldShow to always return false

Now we're up to 3 underscores...

Basically that is one reason extensions break constantly release to release.

See:
https://github.com/JasonLG1979/gnome-shell-extension-mpris-indicator-button/blob/master/mprisindicatorbutton%40JasonLG1979.github.io/extension.js#L29-L61

[JasonLG1979]

IMHO it's a little half-hearted and half-assed on the part of the GNOME devs to ship a stripped down and basically unconfigurable DE and then tell users they can install extensions to provide functionality that they miss but not provide any sort of API for extension devs. But that's just my opinion for what it's worth which is just about nothing,lol!!!

[jakejarrett]

sorry for the late reply, Yeah, seems like something that could be solved with them providing a higher level class / function to use instead of relying on low level functions like these.

Might be worth doing an upstream PR to either add a more stable API for this kind of thing (either for 4+ or 3.33+)

[JasonLG1979]

Might be worth doing an upstream PR to either add a more stable API for this kind of thing (either for 4+ or 3.33+)

I don't think they're really interested in having an API. An official API would mean an expectation that it's at least somewhat stable. They've claimed that GNOME Shell is stable now for a few releases, but we all know that is not the case...

I would just be happy with an official API that points to the main parts of the shell(instead of going though a million underscores) so they could be hidden or moved around easily.

[G0BL1N]

Maybe separating the title name and button for controls could work? Thus you can make title size dynamic without affecting controls placement.
This can be achieved currently with argos-mpris and your extension:

It's not very pretty tho because this is two separate extensions. Maybe could look a little bit better without icon in argos-mpris?
I don't know if this is possible to implement in a single extension, and this is probably too clumsy to exist as a no-option extension, but i thought i'll leave it here anyway.

[adrianocr]

I would personally love if I could see the artist and title displayed. In fact, I don't even need the controls because gnome already has the controls inside the time/calendar dropdown thing plus 9/10 times I just use my keyboard's media keys. What makes me have to reach for my mouse and find spotify under 10 other windows is seeing the artist and title.

[JasonLG1979]

@adrianocr

I would personally love if I could see the artist and title displayed. In fact, I don't even need the controls because gnome already has the controls inside the time/calendar dropdown thing plus 9/10 times I just use my keyboard's media keys. What makes me have to reach for my mouse and find spotify under 10 other windows is seeing the artist and title.

If that's what you want that would be a different extension. If your control point is the menu in the clock I'd say you'd probably want to just put the track info directly in the clock menu title. You'd still need some logic to decide which player's track info to show in the event of multiple players. Not that people generally have more than one player open at a time often, but if there were it would get weird without some kind of sorting logic.

If you just went text = player.artist + player.title every time a player updated those properties it wouldn't work very well.

If you would like I can help you write said extension.

[JasonLG1979]

The sorting for this extension to determine the "Current Player" for example is:

        return players.length == 1
            ? players[0]
            : players.length > 1
            ? players.sort((a, b) => {
                return a.focused
                    ? -1
                    : b.focused
                    ? 1
                    : a.playbackStatus > b.playbackStatus
                    ? -1
                    : a.playbackStatus < b.playbackStatus
                    ? 1
                    : a.userTime > b.userTime
                    ? -1
                    : a.userTime < b.userTime
                    ? 1
                    : a.statusTime > b.statusTime
                    ? -1
                    : a.statusTime < b.statusTime
                    ? 1
                    : a.playerName.toLowerCase().localeCompare(b.playerName.toLowerCase());
            })[0]
            : null;

[adrianocr]

No, no, I was just expressing how important to ME the track and artist info is. I'd still continue to use the controls inside the extension because I feel like they're more convenient to reach for anyway. I don't need a separate extension! I would was just stating that I would appreciate if this one showed artist and track info too haha

[Ferryistaken]

Is the verdict on this feature still declined to implement as of now? I think that including just Song title + Artist + Status of media would be a good balance between ease of use and features of the extension

[JasonLG1979]

Is the verdict on this feature still declined to implement as of now? I think that including just Song title + Artist + Status of media would be a good balance between ease of use and features of the extension

Pretty much everything this is asking for is already implemented as a tooltip.

[Ferryistaken]

I'd like it implemented in the bar, but I can see how you wouldn't want that for simplicity. Thanks for the fast reply.

[JadeVane]

@JasonLG1979

I want to know the information of the song being played at any time, but I don’t like the operation of the mouse. Actually, I already understand your point, but I still want indicator status text, and I can even try to modify the code by hand that I am not familiar with by myself to get it work.

Who likes it, who doesn't and who doesn't care.

I don't kown others' perferences, but it is VERY IMPORTANT for me, and I had been searching something like this for a long time.

There is a problem worth thinking about, that is, many people are just passing by, they don’t care about one more feature or one less feature. but people who can spend time discussing this little feature here are people who need this feature very much.

In fact, more people need this feature than you can see, but they don’t have time for more discussion or just can not speak English, so they just open this issue to learn about the latest developments, and find that nothing change, then close the page with lost mood, as my point, anyone who pays attention to this issue is someone who wants this feature whether they spend time discussing the feature or just open the issue, take a look, and leave.

As you can see, this issue has been paid attention to from 2019 until now, and some people have been responding, so it is time to make changes.

If you would like I can help you write said extension.

I know this request is too rude or too selfish, but tell me how to get it if you are hesitant to make changes, I can modify the code by hand, and just try to see how many people would like this change here.

[JasonLG1979]

I know this request is too rude or too selfish, but tell me how to get it if you are hesitant to make changes, I can modify the code by hand, and just try to see how many people would like this change here.

That offer was made over 2 years ago. I no longer have the time nor desire to teach someone how to code. Even if I did you would not want to be a student of mine. I am not qualified.

It would be great if people would stop necrobumping this issue. It's closed for a reason.

[Ferryistaken]

Ngl, here because the issue was necrobumped, but, would you accept a pull request which implemented this feature as an optional feature toggleable in the settings?

[JasonLG1979]

No