Closed JasonLG1979 closed 5 years ago
Here's a little update on what I have been working on:
The updates include:
Tracklist and playlist interface support.
A quit button.
Slightly better widget alignment.
A separator between players. (still on the fence on this).
An arrow to indicate the current player if there are more than one in the menu. And to indicate current items in the tracklist and playlist menus. I can't use the standard ornament because it uses a Unicode bullet, that the screen reader says aloud when reading the track info. So in the case above it would say. "Spotify; Bullet, Tool, Crawl Away" if I were to use the default ornament.
As always the features require no user interaction. If the player supports them they will show up if not they won't. Above is Pithos and Spotify. Pithos follows MPRIS spec and has support for the tracklist and playlist interfaces (full disclosure: I co-wrote Pithos' MPRIS implementation) and Spotify which doesn't even support all of the player interface.
There are some major internal changes in the pipe for GNOME 3.34 so you can expect an update shortly after Ubuntu 19.10 and Fedora 31 is released.
Another update:
I'm still ironing out a few wrinkles but I should be pushing something for people to start testing tomorrow. I'm still not planning on pushing an update to the extensions site until after Ubuntu 19.10.
The update will include:
3.34 support TrackList interface support PlayLists interface support A quit button Better widget alignment A separator between players An arrow to indicate the current player if there are more than one in the menu Focusing a player will skip the annoying focus stealing prevention "Player is Ready" popup notification and just focus the damn player.
Oh, a feature I forgot to mention. The cover art size is no longer hard coded. The cover art will size it self to the text next to it. That should help it blend in with different themes and scaling factors.
An update has been pushed for the brave among you who are running GNOME 3.34.
Some questions/thoughts:
Why is Position Slider not happening?
I find the current player arrow not a good indicator of what player is selected because it's very similar to the one you have to signal something is a drop down menu. What about a dot instead? Or a colored vertical bar like so:
- Why is Position Slider not happening?
A great many players do not support the feature.
Of those that do a great many mess it up and it's next to impossible to tell programmatically if it works correctly.
It would add a huge amount of complexity for a feature that would work, optimistically 50% of the time.
- I find the current player arrow not a good indicator of what player is selected because it's very similar to the one you have to signal something is a drop down menu. What about a dot instead? Or a colored vertical bar like so:
I didn't use the dot because the screen reader in GNOME Shell reads the name of the dot because the dot is a unicode char not an icon. So what should be "Spotify; Tool, Crawl Away" becomes "Spotify; Bullet, Tool, Crawl Away" when read aloud by the screen reader. I like the sidebar idea if you can get it to match the theme's colors.
- The quit button looks ok but it'd be better if it could be highlighted when moving the mouse over it.
I tried to use built in CSS classes as much as possible. Although the X does light up when you mouse over it. I purposely made it a small target to minimize accidental clicks when user actually intends to raise the player.
Ok I understand for the position slider, that's just too bad...
I don't know how to program the sidebar thing unfortunately. Would you be able to have a look and make it match the theme accent colour?
Ok now that you mention it, I do see the X light up, but it's very subtle. How about making it change colour to red? I understand the decision of making the click area small though.
- How about making it change colour to red?
That's possible. I'll see what I can come up with and see how it looks.
@terencode I tried red and it looked out of place because generally speaking there are no other buttons in the Shell except system buttons at the bottom of the main menu and they aren't red and they are HUGE, I don't want to use their style class.
As far as the arrow icon is concerned I'll look to see if there's a different icon I can use.
I tried red and it looked out of place
What if you try theme accent color?
As far as the arrow icon is concerned I'll look to see if there's a different icon I can use.
Not possible to do the vertical line thing?
What if you try theme accent color?
I can use the same style class of the close button in the overview. I'll see how that looks.
Not possible to do the vertical line thing?
It should be. I'm not what you call a CSS wizard,lol!!! It's trivial to put a line next to items it's another thing to make sure it always matches the theme color and size.
Alright ;)
Here's what it looks like with the default GNOME Shell theme:
I'll check to see what it looks like in Ubuntu's Shell theme if it doesn't look bad I might go with it.
Not bad. What do you think @terencode
Exactly how I envisioned it @JasonLG1979 :ok_hand:
@terencode I still haven't decided. In place of the arrow to indicate the current item I think I'm just going to make my own bullet icon. Probability just a 6 - 8px solid circle. I'm very surprised there isn't already a bullet icon?
What about using media-record-symbolic
?
I saw that but depending on the theme who knows what it looks like. In Ubuntu's theme it's red for example.
Out of ideas then :/ easier to do yourself the bullet than the vertical bar?
Out of ideas then :/ easier to do yourself the bullet than the vertical bar?
For sure.
@terencode OK so I can't get Gtk/GNOME shell to load any icon I create so I'm going to go with media-record-symbolic
for the bullet but it's rather huge (10 - 12px depending on the theme) so I managed to shrink it down with a little CSS fuckery.
As far as the close button after looking at various themes it can look rather weird sometimes so I've decided to go with your original idea and just make it red on hover.
It doesn't look so bad. What do you think?
I used red's from the GNOME icon HIG palette so they shouldn't look horribly out of place anywhere. The icon only goes red on hover otherwise it's just the "X" close window icon. Note that that's the size of media-record-symbolic
at 1/2 size. At full size it's way to big.
There you go @terencode. Try that out and let me know what you think.
Not bad indeed. Here are some minor issues:
The dot is too close to the left menu border, it feels better to have it at half distance
The circle needs one more pixel to its radius, otherwise, the cross is off-centered.
Before:
After:
- The dot is too close to the left menu border, it feels better to have it at half distance
I agree I will see what I can do to move it over just a tiny bit for players.
- The circle needs one more pixel to its radius, otherwise, the cross is off-centered.
I really can't do anything about that. Different themes may and do have different sized dots and placement. What I mean is that the icon itself in total will be 16px but the actual dot itself maybe a different size and be placed anywhere inside the 16px bounds of the icon. I can control the over all size and placement of the icon but not the size of the dot or it's placement inside the bounds of the icon.
For the second point I was talking about the close button.
Here I nudged the bullet over as far as it can go.
For the second point I was talking about the close button.
No part of the close button is defined in pixels. It's all in em. That is done so it scales predicatively since it is next to text and the text pretty much sets the height of the box not counting padding. By default 1.09em = 16px with font scaling at 1. So the close button is 1.635em which = 24px again if font scaling is 1. The close button will always be as close to the center vertically as possible inside the box but it maybe off by a pixel on some themes if (box - button) / 2 != a whole number. You can't render a 1/2 a pixel.
On the default theme it is perfectly centered.
Ah ok makes sense, thanks. The dot looks better now.
Ok, give me a sec and I'll push that.
@terencode There you go. How's that look for you?
Looking good! Thanks for your work.
Are playlists only supported for RhythmBox?
RhythmBox has playlist support although they don't emit the signal that tells client's the names have changed so if you change the name of the playlist there's no way for the extension to know it.
GNOME Music has Spotty tracklist support. Cover doesn't work 1/2 the time.
Clementine has playlist support but tracklists are broken.
Pithos is the only player that has a full fully functioning MPRIS implementation as far as I know. But it's a Pandora client so it's not much use out side the US and a couple other countries.
That's why I made the extension "just work" if a feature is supported it will show up if not it is hidden.
Although "Just works" is strictly as far as the user see's. In the extension it took some tinkering to get there. As far as the tracklist and playlist interfaces are concerned it's not that hard. Basically just don't show the widget if there's nothing to show. But volume and the shuffle repeat features require me to poke the bear. Basically when a player shows up I change the property tied to the feature real quick and change it right back and if I get a prop changed signal I know the feature is supported. I also have to pretty fault tolerant. My fallbacks have fallbacks,lol!!!
Really though there's not much incentive for devs to do a full implementation since most clients don't even support all of the player interface. Spotify's MPRIS implementation is absolute shit for example but you wouldn't know that because it works just fine with most clients. You can get a cover and track info and you can play, pause, skip back and skip forward but that's about all that works.
btw: I've filed the appropriate bug reports on all the above player. Of them GNOME Music is the only one that is actually working on fixes.
It's too bad... Thanks for reporting it. How do they do it on Windows or Mac?
I think MellowPlayer has proper MPRIS implementation. Using it with Deezer allows to fully control position by clicking on the slider, Spotify only reports current position and has basic control.
How do they do it on Windows or Mac?
I have no idea? Haven't used a Mac in almost 20 years and haven't ran Windows except when I have to at work for over 10 years.
I think MellowPlayer has proper MPRIS implementation. Using it with Deezer allows to fully control position by clicking on the slider, Spotify only reports current position and has basic control.
Position is a weird property.
Position is in microseconds.
A property changed signal is not emitted when the Position changes (you wouldn't want a signal every microsecond) unless the player is paused or stopped a client is to assume that playback is progressing normally according to the Rate property. (Rate is a ratio 1.0 = normal speed, 2.0 means 2x speed, 0.5 = 1/2 speed and so on).
Position is read only. To change it you call SetPosition with the trackid and the desired position. But since a lot of players don't implement trackid in metadata SetPosition may not work. You should also not call SetPosition if the CanSeek property is False.
When you call SetPosition you can't assume that it actually worked. You have to listen for the Seeked signal. A player should emit Seeked when Position changes in a way that's inconsistent with normal progress in accordance with the Rate property. Either because SetPosition is called or because position was seeked anywhere else. Many players do not emit the Seeked signal when they should and those that do many return stale/invaild new position values.
There's an edge case that breaks Position. How is a player supposed to tell a client that a track repeated? Should they send the Seeked signal? Should they set PlaybackStatus to "Stopped" to tell the client to reset the position slider? Should the player assign a new trackid to the track so the client knows to reset the position slider?
Spotify does not emit the Seeked signal when it is supposed to, Position always returns 0 and CanSeek is always False. It does however send a track length in the metadata.
In practice that means that viewing the position in a slider works with Spotify in a MPRIS client so long as you don't seek to a position in the main UI. If you do the position in the MPRIS client's UI will be wrong because Spotify does not emit the Seeked signal.
As far as the edge case in 5. In practice a client should already be keeping track of all that. Ofc if the player is stopped the slider should be stopped and returned to the zero position. If the client gets a Seeked signal the position should be changed to that position. And if the client gets a new trackid the position should be started over at zero. But again many clients do none of the 3 when tracks repeat...
Thanks for clarifying Jason. Yeah I asked just in case you knew if the situation was also as bad on other platform :P
@terencode I pushed another bit of tweaks. Could you test it out. I'm thinking if all goes well that I'm going to push this to the gnome extensions site so hopefully it will be approved by the time Ubuntu 19.10 and Fedora 31 are released.
The changelog sounds good to me but it won't start:
JS ERROR: TypeError: iconInfo is null
getSymbolicGiconByName@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/widgets.js:55:5
_init@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/widgets.js:765:34
Player@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/widgets.js:923:28
_init/<@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/widgets.js:1473:39
_addPlayer/</<@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/dbus.js:438:21
onProxyReady@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/dbus.js:269:17
makeProxy/<@/usr/share/gnome-shell/extensions/mprisindicatorbutton@JasonLG1979.github.io/dbus.js:158:29
Otherwise, yes, go for it. it's quite clean now :)
That's strange. How does it look?
It doesn't load the extension, or at least nothing is shown on the top bar.
It doesn't load the extension, or at least nothing is shown on the top bar.
Well that's no good. I don't get any errors on Fedora or Ubuntu. I'll have to check for iconInfo
and fallback to another icon in case it's null
.
@terencode Lets try the big hammer approach. Basically I skipped even trying to add the icon to the theme in the textbook fashion and just create a new file icon strictly from the absolute path to the icon. If that doesn't work something is broken.
It should look something like this with the icons all nice and lined up for the most part.
Ok. The extension loads, but no icon at all.
Ok. The extension loads, but no icon at all.
Are there any errors? This should work. Damn it I'm going to have to build an Arch GNOME system in a VM...
Nope :/
Not an exhaustive list of all of the features and settings from gnome-shell-extensions-mediaplayer, more of a general list of features I have seen people asking about or features that I personally like/use. If you don't see a feature specifically listed the answer is most likely going to be "Not happening."
You are of course free to takeover maintainership of gnome-shell-extensions-mediaplayer or fork it and/or this extension and do the work yourself if you see anything on this list that you don't like.
Position Slider: Not happening.
Ratings in any form: Not happening.
Changing position of the indicator or putting it in the system menu: Not happening.
Album covers in the panel: Not happening.
Playback status in the panel: Not happening.
Track info text in the panel: Maybe. See here
Repeat and random buttons:
Maybe.DONETrackList and PlayList interfaces: Maybe.