Bug#566174: gtk apps set WM_COMMAND incorrectly on the leader window

[anomie at users.sourceforge.net]

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).