You are not logged in.

#1 2019-11-09 08:05:45

Registered: 2019-11-07
Posts: 2

Making changes to WM_CLASS persistent?

Hello all!

First post here so I hope you will be gentle with me. smile

Im using awesome window manager and Im having some trouble with a few applications that wont start in my desired tab. For example Im using ATLauncher and according to xprop its WM_CLASS(STRING) value is "com-atlauncher-App" but that doesnt work if I use that value in my rc.lua.
However if I start ATLauncher and use

xprop -name "ATLauncher" -f WM_CLASS 8s -set WM_CLASS "atlauncher"

and change my rc.lua value to "atlauncher", it works when I restart my x-server. The issue then is that it isnt persistent.

Is there a way to make it persistent? Desktop entry? Bash script? Alias? Another clever way?

I would be very thankful if someone could point me in the right direction.

Last edited by patz (2019-11-09 08:46:21)


#2 2019-11-09 13:34:57

Inspector Parrot
Registered: 2011-11-29
Posts: 22,284

Re: Making changes to WM_CLASS persistent?

patz wrote:

Is there a way to make it persistent? Desktop entry? Bash script? Alias? Another clever way?

Yes, any of those would work depending on how you want to normally launch it.

But it'd be better to set things up right in the first place rather than trying to find a work around.  Note that WM_CLASS is a bit confusing and often misunderstood.  There should should be two values in WM_CLASS, one is the res_name and the other res_class.  Because both of these are components of WM_CLASS there is often ambiguity when tools like WMs have a field for specifying the window "class".  Window "class" almost always refers to one of the members of WM_CLASS, but sometimes it is actually res_class other times it is res_name.  Other times WMs will have a field for "name" and this can then either be res_name of WM_CLASS, or WM_NAME*.  So it's a mess - but once you figure out which one your WM is actually using, it should work.

Please post the complete xprop output for the window of interest as well as the relevant section of your rc.lua.

*sidenote: WM_NAME is very rarely used for these purposes as it is much less predictable than the WM_CLASS values as WM_NAME often changes many times while a program is running.

Last edited by Trilby (2019-11-09 13:39:41)

"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman


#3 2019-11-09 14:09:04

Registered: 2019-11-07
Posts: 2

Re: Making changes to WM_CLASS persistent?

Thanks a lot for replying, really appreciate it.

xprop output (the icon part excluded):

                window state: Normal
                icon window: 0x0 = 
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x3d, 0x0, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
                Client accepts input or input focus: False
                Initial state is Normal State.
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x2c, 0x3a, 0x0, 0x0
_NET_WM_ICON(CARDINAL) =        Icon (128 x 128):
WM_CLASS(STRING) = "com-atlauncher-App", "com-atlauncher-App"
WM_CLIENT_LEADER(WINDOW): window id # 0x800008
WM_NAME(STRING) = "ATLauncher"
                user specified location: 1920, 188
                program specified location: 1920, 188
                program specified size: 1198 by 698
                program specified minimum size: 1198 by 698
                program specified maximum size: 1198 by 698
                window gravity: NorthWest


{ rule = { instance = "com-atlauncher-App" },
       properties = { screen = 2,tag = " minecraft  " } },

I guess that is the relevant part, otherwise this is my complete rc.lua

Yes, Iv understood from reading around that WM_CLASS seems to confuse people. I do understand that there is a difference between class and instance and also that WM_NAME is rarely used, Im just confused on "where to start" to really learn and understand this. Do I focus on my window manager? Can it be defined in X-server through .Xresources? I understand there are multiple options here, how would you go about solving this?

EDIT: I usually run my applications through awesome, with modkey+r

Last edited by patz (2019-11-09 14:10:23)


#4 2019-11-09 15:05:30

Registered: 2012-05-17
Posts: 3,586

Re: Making changes to WM_CLASS persistent?

This is a java application, so maybe they set the WM_CLASS "too late"? I guess awesome checks the class/instance when the window is created, but java might create the window with a different value and only change it afterwards? You could try to listen to the property::class signal.

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |


Board footer

Powered by FluxBB