spotifywm: No longer working with Spotify 1.1.55
After updating Spotify to latest 1.1.55.498.gf9a83c60, spotifywm is no longer working.
Output looks OK:
[spotifywm] attached to spotify
[spotifywm] attached to spotify
[spotifywm] attached to spotify
[spotifywm] attached to spotify
[spotifywm] spotify window found
But the window manager no longer applies any settings to the Spotify window on startup.
This same setup was working on previous versions of spotify-client, with nothing else changed.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 19
- Comments: 28 (1 by maintainers)
I’m not too terribly familiar with how X works but I compiled a shared library very similiar to
spotifywm
that intercepts all of the windows creation and mapping functions I could find:and is compiled with:
Long story short, booting spotify outputs the following:
showing the creation of three windows and the mapping of two. The issue seems to be though that the parent window for the latter two create calls is somehow owned by Spotify according to
xlsw -r
:and doesn’t have it’s name or class set prior to being mapped (and we don’t see a mapping call being intercepted for that window ID). I’ve tried setting the class hint of the parent windows in the latter two mapping calls however it seems like that’s too late as my
bspwm
rule still doesn’t handle the spotify window properly.Hoping someone more familiar with X may know how else the
0x5e00008
window in the above example could be getting created and/or mapped.EDIT: Also potentially worth adding that
xprop
gives the Spotify window’s id as0x5e00008
as well, not one the the windows we see being mapped above.Same stuff on DWM
No!! don’t update!! give us the old version!!!
@mohad12211 You have to edit the rule matching code, which is inside the
applyrules()
function indwm.c
.Not at all an elegant solution, but I hacked a similar workaround for dwm:
In case I ever update it, here it is inside my build: https://github.com/BachoSeven/dwm/blob/master/dwm.c#L404
P.S. I found another window which has an initially broken class: Chromium’s Task Manager, the one brought up by
Shift+Tab
.Same on XFWM4 with devilspie2. Devilspie2 sees both the window title and the app name as “Untitled window”, so here’s what I’m doing to work around it. The idea is that if both values are set to that and the spotify process is less than three seconds old, it’s reasonable to assume that the window belongs to Spotify. It could be reasonable to presume that Spotify is the only application on a given Linux desktop that would misbehave so flagrantly, but better safe than sorry.
Same on sway