Type in your question below and we'll check to see what answers we can find...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
Please see below the most popular frequently asked questions.
Please see below the current ongoing issues which are under investigation.
Loading ongoing issues...
Operating System Version:
Debian Stretch (testing)
Imposible to match Spotify window when it is created using WM_CLASS propety. WM_CLASS property is not set early enough at startup.
In i3 WM try the following configuration and start spotify:
assign [class="Spotify"] 3
This should force Spotify to be assigned to workspace 3 but since the class property is not matched, the rule is ignored.
Solved! Go to Solution.
You can try preloading spotifywm. I hacked it down in an hour and I hope it works.
Thanks for posting.
I've moved your issue into the Desktop help area.
This is the best place to get help and resolve issues in the Linux client.
Same issue here. From a workaround in https://github.com/i3/i3/issues/2060 I have been able to get it working.
assign [class="Spotify"] $workspace10
for_window [class="Spotify"] move to workspace $workspace10
makes the trick. It creates the window in the current workspace and when the class is declared the window is moved.
Note: $workspace10 is the variable in my system, change accordingly with yours.
I have this problem as well. Using BSPWM on Arch.
Pretty sure this shouldn't have been moved to the Help - Desktop section since it's a bug or an ICCCM noncomplience issue that was introduced with the redesign.
Also experiencing this issue, but with compiz config settings mananger and unity.
Any updates on this issue? Currently using the workaround (thanks biovgg) but it'd be great to have an actual solution.
I can confirm that this is still a problem in the current version.
Spotify only sets it's WM_CLASS property after mapping itself, which is against the ICCCM specifications:
This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state
Changing the class after mapping the window will break a lot of programs, like window managers and taskbars (some of which are mentioned in this thread).
I agree. It makes sense. We are most certainly doing things in the wrong order, which doesn't matter on Win/Mac, but it does on Linux. I can't see it immediately, my CEF/X skills are pretty bad. There is an old internal bug tracking this issue since last year, so at least it is on the todo list.
Not sure if that helps, but the spotify executable contains a call to XLibs "XSetClassHint()", so I would guess that you (or a statically linked library) are using that to set the WM_CLASS.
Yep. We are setting it in with XSetClassHint in the Spotify code.
I've talked to Marshall, the creator of CEF, and he gave me some pointers. The way we use CEF now, means CEF creates the top-level window, and there is no way to get the window handle after creation and before it is mapped.
We will "soon" switch the desktop client to use CEF with the Views architecture instead, which means the Chromium code will create and map the window. With Views there is a way to tell Chromium to set WM_CLASS correctly, by setting some widget parameters.
I kind of know how to fix it now in CEF when I have time.
Hey, I'm a "bit" new to linux and I'm not sure where the spotify binary is in regards to this
For me (Arch Linux) /usr/share/spotify/spotify worked
I too have this problem ... looking forward to the official fix since workarounds didn't work for me so far (running Compiz)
I would like to know if this subject could be tackle. Is it still in your todos list? Have you already switch to View Architecture?
Hey there you, Yeah, you! 😁 Welcome - we're glad you joined the Spotify Community! While you here, let's have a fun game…