Window manager matching for Spotify window

0x000000 · 2015-11-03 04:13:36

I'm using Spotify from AUR and with a recent release, I've noticed that on any WM I use, I can't get the Spotify client window to match using the WM's rules. I've tried xmonad, Fluxbox, and i3, but the problem is the same with all of them.

This is the relevant output from xprop:

_NET_WM_ICON(CARDINAL) = 
WM_CLASS(STRING) = "spotify", "Spotify"
WM_NAME(STRING) = "Spotify"
_NET_WM_NAME(UTF8_STRING) = "Spotify"
XdndProxy(WINDOW): window id # 0x2a00002
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		window gravity: Static
_NET_WM_PID(CARDINAL) = 9415
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "selfy"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING

i3:

assign [class="Spotify"] 6

Fluxbox:

[app] (Class=Spotify)
  [Workspace] {2}
  [Maximized] {yes}
[end]

xmonad (in composeAll hook):

className =? "Spotify" --> doShift "music/6",

Anyone else been running into this problem? Is there any way in any of those WMs to get a log of the windows that are created (i3 preferably as that's my current fave)? I'm thinking something funny's happening with the way the Spotify window is created.

Trilby · 2015-11-03 12:06:25

Have you tried lower case "spotify"? The WM_CLASS has two values which have unfortunate terminology, currently you are matching against the class-class rather than the class-name. I think many WMs will match against the class name, which according to your xprop output is lower case.

berndbrot · 2015-11-25 14:52:52

I had the same problem, neither "spotify" nor "Spotify" works. However

className =? "" --> doShift "music"

did the trick for me. It seems as if the WM_CLASS is not set during spotify startup but gets changed later. This might become a problem when other applications behave the same way as they'll also be moved to the "music" workspace, but for now all applications I use set the WM_CLASS correctly.
It would be great to know if one can shift windows around whenever their WM_CLASS changes, but a quick web search didn't reveal anything useful to me.

Trilby · 2015-11-25 17:17:47

berndbrot wrote:

It would be great to know if one can shift windows around whenever their WM_CLASS changes, but a quick web search didn't reveal anything useful to me.

It's absolutely possible. But this is up to the window manager to respond to property change events to catch these changes. Most window managers only check WM_CLASS during the initial mapping of the window. This makes sense to me: WM_CLASS really shouldn't change while the window is mapped - in fact doing so runs counter to the ICCCM. WM_NAME and numerous other properties can be much more dynamic, but WM_CLASS should not be.

Further the ICCCM also requires that WM_CLASS be set before the window is mapped (or returned from a withdrawn state). As this is not the case for spotify, this should be considered a bug and it should be reported upstream.

ICCCM wrote:

The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information. 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, but there should be no need for a client to change its state dynamically.

emphasis added.

Arch Linux

#1 2015-11-03 04:13:36

Window manager matching for Spotify window

#2 2015-11-03 12:06:25

Re: Window manager matching for Spotify window

#3 2015-11-25 14:52:52

Re: Window manager matching for Spotify window

#4 2015-11-25 17:17:47

Re: Window manager matching for Spotify window

Board footer