2

I'm trying to start an application (Spotify) on a particular tag. Rules aren't applied and now I'm inspecting the client class by printing the class in a notification in the "manage" signal. This results in an empty notification.

client.connect_signal("manage", function (c, startup)
    naughty.notify({title=c.class})
end)

When I restart awesome, it does print the client class, so why isn't it working when the client is initially started?

Using xprop, it also prints the class: WM_CLASS(STRING) = "spotify", "Spotify"

siebz0r
  • 18,867
  • 14
  • 64
  • 107

2 Answers2

2

Sounds like a bug in Spotify (and I think I heard about this one before). I would guess that Spotify does not follow ICCCM and only sets its WM_CLASS property after it made its window visible and not before.

I fear that you cannot do much about this except for complaining to Spotify devs to fix their stuff.

You could work around this by starting a timer in the manage signal that checks if a window turns out to be spotify a short time later. Alternatively, you could do something like client.connect_signal("property::class", function(c) if c.class == "Spotify" then print("This is now a spotify window") end end) to react to change to a window's class (of course you'd want to do something more useful to Spotify's windows than printing them). (Per the ICCCM, a window is not allowed to change its class while it is visible, but who cares about standards...)

Uli Schlachter
  • 9,337
  • 1
  • 23
  • 39
1

I had a similar issue with the claws-mail client. Inspecting it via xprop, it shows

WM_CLASS(STRING) = "claws-mail", "Claws-mail"

but awesome just did’t apply the rules for it. The trick was giving awesome-wm both of these class names in the rules section by providing a set of characters to chose from:

rule = {class = "[Cc]laws%-mail"}

I hope this works for your spotify application, too.

For further reading about patterns in lua I suggest this: https://www.lua.org/pil/20.2.html

Neige
  • 21
  • 3