Package: libgtk2.0-0
Version: 2.18.6-1
Gtk apps but don't set WM_COMMAND correctly on their leader window. Most
end up setting it to just the filename component of argv[0], while a few
that call g_set_prgname before gtk_init set it to whatever name was
passed to g_set_prgname, which may not even be an extant command name or
may even refer to a different program. Interestingly, the real client
window somehow gets the correct WM_COMMAND set (even though it should
have no or a zero-length WM_COMMAND since it is not the group leader).
I've attached a minimal test program. Running the program will just open
a blank window. Inspecting this window with xprop will reveal a
WM_COMMAND with the correct information, including the path and command
line arguments, something like this: (extraneous output snipped)
WM_COMMAND(STRING) = { "./foo", "bar", "baz" }
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
window id # of group leader: 0x5600001
WM_CLIENT_LEADER(WINDOW): window id # 0x5600001
Inspecting the client leader window (0x5600001 here) shows the incorrect
WM_COMMAND:
WM_COMMAND(STRING) = { "this-will-be-wrong" }
This incorrect WM_COMMAND can cause problems for other programs that may
want to know how to re-execute a running gtk program (e.g. kept dock and
clip icons in wmaker, which is how I noticed this issue).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
