New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No longer working with Spotify 1.1.55 #8
Comments
Experiencing the same problem. I installed today bspwm and spotify doesn't follow the rules that I put in the bspwmrc. [spotifywm] attached to spotify In the bspwmrc I put: |
Same stuff on DWM |
same on xmonad |
Same on sway |
I'm not too terribly familiar with how X works but I compiled a shared library very similiar to
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
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 Hoping someone more familiar with X may know how else the EDIT: Also potentially worth adding that |
By changing the code in XMapWindow to say "notspotify", I get:
And with awesomewm I can reload my window manager, which then reapplies all the rules and correctly send spotify to my desired tag. That shows that the rules query 0x01600007, even though the second line is the window id from xprop (in my case it is 0x01600008), and the only window we seem to be able to affect is the bottom one. |
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. if win_name == "Untitled window" and app_name == "Untitled window" then
-- Let's find out if Spotify just started.
handle = io.popen("pgrep -o spotify")
proc = "/proc/"..handle:read()
handle:close()
handle = io.popen("stat -c%X "..proc)
stat = handle:read()
handle:close()
if (os.time() - stat) < 3 then
debug_print("Spotify just started; this window likely belongs to it.")
set_class("Spotify") -- Custom function to change the class for the rest of the scripts.
end
end |
hey, any update? thx |
I made an update to the tiler for pop-os that detects WM_CLASS change and then re-tiles. This same method could be used to fix other tiling wms |
@msdrigg cool, how did you do? I'm using |
@andrevandal I submitted a pr for pop-shell here pop-os/shell#1174. You can install from github to have these changes on your system, but its not going to be available on a release for awhile. There are some additional issues with the latest spotify flatpak, so if you do upgrade, make sure you are using the spotify snap or the regular deb. |
Not at all an elegant solution, but I hacked a similar workaround for dwm: /* rule matching */
c->isfloating = 0;
c->tags = 0;
XGetClassHint(dpy, c->win, &ch);
if (0 == system("[ $(ps -o etimes= -p $(pgrep -o spotify)) -lt 3 ]")) {
class = ch.res_class ? ch.res_class : "Spotify";
} else {
class = ch.res_class ? ch.res_class : broken;
}
instance = ch.res_name ? ch.res_name : broken; 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 |
interesting, where exactly do I put this code in dwm? @BachoSeven |
@mohad12211 You have to edit the rule matching code, which is inside the |
@BachoSeven thanks for the workaround, but it doesn't work unfortunately. atleast on my system it doesn't. |
@wael444 how exactly? did you change the code, recompile, add a rule for the |
i added the snippet. and reloaded
i only checked the class name using however the rule applies to it anyway? i kinda expected WM_CLASS to change as well but in dwm it follows the rule specified. i it works...? i think. |
To clarify: what I did is make it so any window which both spawns 3 seconds after a |
hey @BachoSeven, when I do
when I reload my dwm, Spotify gets into the designated tag, but when I try to open Spotify, it opens in the present tag only. ig your patch would not benefit me as I am getting the correct and any idea how to fix this ?? |
are you sure that you applied the patch correctly? |
@samyak039 regarding your last observation, the point is not that the |
thanks @BachoSeven for explaining. @mohad12211 afterwards I applied the patch, but Spotify is still not obeying the tag rule. I added the patch mentioned by BachoSeven, in /* rule matching */
c->isfloating = 0;
c->tags = 0;
XGetClassHint(dpy, c->win, &ch);
if (0 == system("[ $(ps -o etimes= -p $(pgrep -o spotify)) -lt 3 ]")) {
class = ch.res_class ? ch.res_class : "Spotify";
} else {
class = ch.res_class ? ch.res_class : broken;
}
instance = ch.res_name ? ch.res_name : broken; and have also added this in my /* class instance title tags mask isfloating isfakefullscreen monitor */
{ "Spotify", NULL, NULL, 1 << 7, 0, 1, -1 }, but still the Spotify is opening in the current tag. |
@samyak039 Not sure I can help then, however I am also using |
my only workaround at the moment is this script:
|
{"Spotify", NULL, NULL, 1 << 3, 0, -1}, Never mind, I am running an older version of Spotify, 1.1.10 |
only after adding the rule and the change in in theory this shouldn't be possible. |
Sorry for the confusion, I'm running an older version of Spotify. |
No!! don't update!! give us the old version!!!!! |
After updating Spotify to latest 1.1.55.498.gf9a83c60, spotifywm is no longer working.
Output looks OK:
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.
The text was updated successfully, but these errors were encountered: