Wayland support

[okidian]

Hi,

Can you release a linux package with ozone support built so that we can use the client under Wayland? There have been posts requesting this in the past because it is highly anticipated.

It shouldn't be that complicated it seems:

https://www.collabora.com/news-and-blog/blog/2019/05/08/cef-on-wayland-upstreamed/

https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/ozone_overview.md

Best,

[pgomes]

Hi Phiro69, version 1.2.20 was released as Edge at Snap, and Unstable at the Deb repo. This fixes the media player issue in Wayland, and adds the tray icon support. Please not that it's still experimental, and might require few adjustments. From now on I will try to release a new version monthly. Also, I plan to take a look at the Wayland detection next time I'm given some time. But again, no promises.

[no4b]

Because Spotify didn't have tray icon for so long I moved to pining it to taskbar. Now I have two Spotify icons which is just redundant (the one pinned to KDE's taskbar has options like play next, previous etc which makes it much more useful). Make try icon optional please.

[BryanLiang]

The drop down menu in Settings is still unusable in the latest version(1.2.20).

Besides, Spotify uses CEF as its GUI framework which shares  some commons with Electron. So I tried passing the argument `--enable-wayland-ime` to enable input method support for Spotify on wayland, but it makes no difference. It would be better if input method is usable on wayland.

UPDATE 2023/10/06

Spotify works with `enable-wayland-ime` parameter.

[Phiro69]

Thanks, I'm on 1.2.20.1210 now, with 

Exec=spotify --enable-features=UseOzonePlatform --ozone-platform=wayland %U

in /usr/share/applications/spotify.desktop,

What isn't working for me:
1) I still get the Windows XP framing
2) While the Settings menu looks good, no pulldowns inside of Settings work. I see the pulldown flash in the very upper left of my usable desktop for about ~50 ms, however long the open & close animation takes. 

3) The running dock icon still isn't recognized as Spotify

What works for me:
1) Media keys work great (Ubuntu 23.04)
2) I do see Chrome is upgraded to 115, that's an improvement 🙂

[pgomes]

I see. As a solution, I am considering to only show the tray icon when the option "Close button should close to the Spotify icon". Would this work with your own tray icon?

[no4b]

There is already "Close button should minimize the Spotify window" option. I think that it would make sense to show new tray icon only when this option is checked.

[pgomes]

Hey no4b. I also thought at first that "Close button should minimize... " would be used for that. But strictly speaking, this option is about the close button behavior. Also, in this first implementation I simply mimicked the Windows client behavior. Still, we in the Linux client can take decisions independently. So, I have already brought this point. And few others, such as adding "play/pause", "forward", etc at the tray icon. You can keep on posting your opinions, I'll bring them to the discussions

[pgomes]

The code that makes the tray icon optional was merged today. It will be available in the next unstable release, in about 2 weeks

[xconauz088]

Please make the X11 libraries optional. Workaround for now:
https://community.spotify.com/t5/Desktop-Linux/Wayland-support/m-p/5320462/highlight/true#M20892

[pgomes]

Version 1.2.22 was released today to Unstable/Debian and Edge and Candidate/Snap. I makes the tray icon optional to the "Close button should minimize the Spotify window" setting.

[no4b]

Thank you 🙂

[Steasenburger]

Hi @pgomes,

First of all, thank you for working on the Linux Spotify client! I never thought that we would get official Wayland support at some point.

One small bug report: I noticed that the Spotify icon is not shown in the Dash-to-Dock extension, which is used by Manjaro by default.

I've noticed this problem for a few Chromium-based native Wayland apps.

It only appears when you start Spotify with the Wayland-specific flags. Without them, the Icon is correctly shown.

[Feng_Lengshun]

AFAIK this is an issue with Chromium (and so, electron) apps on Wayland in general. I tried running Chrome in true Wayland (not XWayland) and it has a generic Wayland icon. It's an issue with Wayland generally, and DtD likely have some issues handling that, using a wrong icon similar to how Steam can bug out with the wrong window title.

(I run with `flatpak run --branch=stable --arch=x86_64 --command=chrome --file-forwarding com.google.Chrome --enable-features=UseOzonePlatform,Vulkan,WebRTCPipeWireCapturer,VaapiVideoDecoder,WaylandWindowDecoration,VaapiVideoEncoder,UseSkiaRenderer,WebUIDarkMode --enable-unsafe-webgpu --enable-gpu --ozone-platform=wayland --force-dark-mode` to be exact)

[BryanLiang]

You can try adding this line `StartupWMClass=spotify` to the desktop file to see if it helps.

[pgomes]

Hi all, the icon problem in Wayland is known, and as I mentioned here, it depends on a fix from the underlining graphical library. I am still waiting a reply from them

[Stealth77]

Your link in your last post seems to be broken (at least for me). Would you be able to fix it?

In an addition to the Wayland icon problem, with non-integer scaling (I use 1.25x and this is the main reason I'd like Spotify to run natively on Wayland), the application seems to think the cursor is in a different place as to where it actually is making the UI extremely difficult to use. Does anyone else have this problem?

[pgomes]

The link is also broken for me, probably I made some mistake. Here's the thread about the Wayland icon

I will try non-integer scaling soon to see if I can reproduce it. But if there's actually such bug, this is likely to be something inherited from Chromium. Can you confirm that the same happens with Chromium?

[Stealth77]

I think there's a confusion about two different icon issues here. The thread you link is about the tray icon. However the posts in this thread (and the issue I was referring to in my above post) is about the taskbar icon. When launching Spotify on Wayland, the icon is a generic one, e.g. on my desktop environment (KDE Plasma):

Generic Wayland taskbar icon.

In many DEs, if it can't determine the taskbar icon for a window, you can sometimes fix this by adding the `StartupWMClass=<name>`  to the desktop file which matches the icon in there to windows with the `<name>` window class. Unfortunately the window class is null. There isn't a good way to do this that's DE-independent so on KWin (KDE Window manager) I used the command `qdbus org.kde.KWin /KWin queryWindowInfo` and clicked on the Spotify Wayland window which prints information including the line `resourceClass: `. Most other windows have this filled e.g. for Chromium, it's `resourceClass: chromium-browser`.

WRT non-integer scaling with Chromium, I don't have the same problem and everything is good there (including the Spotify web player). This is with v118.0.5993.

[Phiro69]

I reloaded my work machine with Mantic Minotaur (23.10) over the weekend and spotify-client debian is reliant on a library that was apparently removed over the summer: 

spotify-client : Depends: libgconf-2-4 but it is not installable

So, I'm now using the web client installed as an app on chrome-stable 😕

Not asking for a fix in this thread (since this is ostensibly about Wayland support in the debian), I'm just giving this out as a PSA/heads up to anyone thinking of a fresh install of Mantic.

[pgomes]

Hey Phiro69, thanks for the info. Indeed the DEB package required libgconf-2-4, which is deprecated since Mantic. I am checking now how to no longer depend on such package. From a preliminary look, it seems possible with not much effort