window grouping using WM_CLASS under x11/XDG desktops

[sebshader]

desktop shells implement application window grouping using WM_CLASS (and the XClassHint structure) 'hints'
https://linux.die.net/man/3/xclasshint

The XClassHint structure contains:

typedef struct {
   char *res_name;
   char *res_class; 
} XClassHint; 

The res_name member contains the application name, and the res_class member contains the application class. Note that the name set in this property may differ from the name set as WM_NAME. That is, WM_NAME specifies what should be displayed in the title bar and, therefore, can contain temporal information (for example, the name of a file currently in an editor's buffer). On the other hand, the name specified as part of WM_CLASS is the formal name of the application that should be used when retrieving the application's resources from the resource database.

however it seems like most apps/shells expect that for instance to group windows under the same icon in xfce4-panel (and to use the pd icon) the res_name field of XClassHint should be the same.
it also seems like many shells may also support having the res_class field reflect the name of the .desktop file (without the .desktop extension).
I'm unclear on if it's possible to use the same res_name for multiple tk windows; to me it looks like Tk actively prevents this:
https://www.tcl.tk/man/tcl8.6/TkCmd/tk.htm#M5 (though perhaps there's some way to set it without tk appname?)..

I have been able to get the pd icon to show up for just the pd window (for xfce4-panel) by setting StartupWMClass=pdwindow in the desktop file.
I think if it would be possible to set -class for toplevels to something else that would conform to what many shells do with these 'hints', like setting it to the name of the desktop file or something (but I haven't tested this yet), or by setting it to whatever StartupWMClass is set to in the .desktop file.
If so perhaps it could be part of adopting a more class-like structure for the pd gui processes, where a 'window type' is stored in some kind of instance field for a window/toplevel patch sent to the gui-side in a standardized way instead of as a tk class, which would reflect the classes 'coming from' pd rather than being specific to the gui used. (of course it would be implementation-specific anyways, but imo it makes sense to standardize sending/storing some class-based object state on the gui side for a given object)

[sebshader]

if I start 2 instances of pd using StartupWMClass=pdwindow the pdwindows group together under the correct pd icon, but all patch windows are separate without the icon. using xprop, the pdwindow's WM_CLASS is

WM_CLASS(STRING) = "pdwindow", "PdWindow"

whereas the PatchWindows have WM_CLASSes like

WM_CLASS(STRING) = "x55a688103a80", "PatchWindow"

the 1st field, the res_name, seems based on Tk_GetUid (and as previously mentioned is probably prevented from being shared anyways if tk appname were used)

edit: I wonder if wm iconname could be used to group as well...
similarly wm group might work, but I'm not sure it's doing the same thing or not: "The window manager may use this information, for example, to unmap all of the windows in a group when the group's leader is iconified."
that doesn't seem like the same thing, and also seems too inflexible for pd

edit2: it also works if I use "PdWindow" for StartupWMClass, which makes me think that it would work to use a single class for all pd windows..

[sebshader]

when I hover over the icons that represent the windows in xfce4-panel, the popup box that allows the window to be closed also uses the correct icon (as well as the title bar for the window). Somehow correct icons are attached to the windows, but not their grouping/panel icon.
I suppose the process from the .desktop file always uses the icon specified in it, but xfce4-panel doesn't know how to group the windows together/the icon for that group..

[sebshader]

so setting StartupWMClass=PatchWindow works to use the correct icon/grouping for patch windows. this indicates that if pd could use a single class for all toplevels (like PdWindow) they would be grouped correctly, (if StartupWMClass is set to PdWindow)

[umlaeute]

so what exactly is the problem you are trying to solve?

• that the main Pd-window and PatchWindows are grouped differently? (I presume: in the task bar)
• that multiple instances of Pd are grouped together?
• ...?

[sebshader]

@umlaeute there are a couple problems:
imo the main one is that the pd icon referenced in the .desktop file doesn't get used because the desktop doesn't know to associate specific windows with it.
the other one is when the hint IS specified e.g. throughStartupWMClass that only 1 class of windows gets mapped to the specific icon file (and grouped together), while the other classes of window use whatever the default icon is for application windows in the desktop and aren't grouped at all.
Ideally the windows from one pd-gui process would be grouped together I think. but at this point it seems like that would involve them all having the same class..

[umlaeute]

imo the main one is that the pd icon referenced in the .desktop file doesn't get used because the desktop doesn't know to associate specific windows with it.

not sure i can reproduce this.
with the Debian installed packages (which I think use the .desktop file and icons as-is) i get the correct icons for both the Pd window and any patch window (using xfce4)

the other one is [...]

that would be my item No.1, yes?

Ideally the windows from one pd-gui process would be grouped together

that would be my No.2, yes?

[sebshader]

@umlaeute yes.
I'm kind of confused because I'm also on xfce4 using Mx-Linux (debian-based). I installed 0.53 from source

[sebshader]

However, other apps like firefox group windows from multiple processes together so maybe having them separate isn't normal

[sebshader]

@umlaeute I tried installing apt install puredata/bullseye-backports and apt install puredata-gui/bullseye-backports. same behavior (0.53)

[umlaeute]

I tried installing

you sure you are using the packaged Pd, rather than the self-compiled?

the desktop-file shipped with puredata-gui will happily pick pd-gui from /usr/local/bin if there is one...
i think the only way to actually force the correct Pd-GUI, would be to launch /usr/bin/pd-gui from the console.

[sebshader]

sudo make uninstall
which pd -> nothing
which pd-gui -> nothing
ls /usr/local/share/applications > just mimeinfo.cache
sudo apt install puredata-gui/bullseye-backports puredata/bullseye-backports -> "Selected version '0.53.0+ds0-1~bpo11+1'"
which pd-gui -> /usr/bin/pd-gui
restart computer
Pd from whisker menu or /usr/bin/pd-gui ->

[sebshader]

@umlaeute when we say 'icon for a window' I'm talking about the icons for the window in the xfce-panel, not the icons in the windows themselves which are correct

[sebshader]

with StartupWMClass=pdwindow:

[umlaeute]

@umlaeute when we say 'icon for a window' I'm talking about the icons for the window in the xfce-panel, not the icons in the windows themselves which are correct

This is what I'm talking about as well.
(I'm afk for the weekend so I can't post a screenshot)

[umlaeute]

so here's my xfce-panel:

as soon as i have multiple Pd-windows open, they group together as "pd-gui", but both the main Pd window and the patch windows have the Pd-icon.

[sebshader]

huh my xfce-panel is completely different. maybe it's a different version? if so I guess it could be an issue on their end.
my version is 4.16.3
I can't imagine mx linux doing too much to mess with it, but on mine it's just icons (no application/process name)

[sebshader]

@umlaeute I was using 'docklike taskbar' panel item, which doesn't group the windows correctly or have the correct icon.
but, if I switch to using the 'windows button' item which is what you have in your taskbar, and then turn on window grouping it does group and use the correct icon.
So it seems like the 'window buttons' taskbar item uses the icon associated with the windows/process, whereas the 'docklike taskbar' uses these window shell hints

[umlaeute]

thanks for investigating on this.
it seems like Debian (still) doesn't ship the xfce4-docklike-plugin, so it's a bit hard to test for me right now :-)