GNOME Bugzilla – Bug 77942
Title of grouped applications looks bad
Last modified: 2007-06-29 19:34:29 UTC
Using the name of the binary for grouped applications seems bad. From a ui perspective, I find it confusing (especially for new users). Instead maybe we can use the title of the last focused window. I'm not sure though, this is a messy problem.
The fix here is to add a GTK feature to set the application name where libwnck can get it. There's nothing to do other than that.
We should make something up probably, or at least hardcode a Mozilla workaround.
*** Bug 155878 has been marked as a duplicate of this bug. ***
Comments from 155878: It would be nice to improve the title of window groups. One way might be to get the WM_COMMAND from the window properties and look that command up in .desktop files. This won't work if no .desktop file exists for the application, and might not work well on remote applications. Still, this should improve the display quite a bit. When windows are grouped, and one of the grouped windows is the active window, the icon and the title of the grouped window should be from the active window.
Actually bug 155878 wasn't a complete duplicate, since it also mentions the icon. But I think that's covered by bug 142569.
The current mechanism tries to fetch _NET_WM_VISIBLE_NAME and _NET_WM_NAME from the group leader. glib offers g_[get|set]_application_name since 2.2, but I don't know how it works together with the said xatoms.
Chris: No, the current mechanism only does that for ungrouped windows. This bug is about the name for grouped ones, which uses WM_CLASS (see update_name() of libwnck/libwnck/application.c). Also, to see how g_[get|set]_application_name works with xatoms, look at http://freedesktop.org/Standards/wm-spec/1.3/ar01s05.html for the definition of _NET_WM_NAME and _NET_WM_VISIBILE_NAME, and see gtk+/gdk/x11/gdkwindow-x11.c for the Gnome implementation (g_get_application_name is used in the get_default_title() function which is in turn used by the check_leader_window_title() to set _NET_WM_NAME).
Retitling, since title isn't accurate currently.
See libwnck/libwnck/class-group.c:set_name(). This is what tries to figure out the name for the class group using a few heuristics (the class group is what you see as groups in the task list): 1. Try to get the class group's name from the group leaders. For each window in the class group, get the group leader. Compare the names of all the group leader windows. If all names are equal, then that gets used for the class group name. What gets tested is _NET_WM_VISIBLE_NAME, then _NET_WM_NAME, then XA_WM_NAME, as fallbacks of each other. 2. If the names were different, try the individual window names instead. If all are equal, then use that for the class group name. What gets tested is the same set of fallbacks as in (1). 3. If (1) and (2) both fail (e.g. not all the group leader names are equal, or not all the window names are equal), then use the resource class. This should only happen for really crappy/old clients. Clients should really be settings sane _NET_WM_* values. Each time a .desktop file needs to get matched to the binary name as a fallback, we should send a flaming bat out of hell to chomp off the author's head.
Federico: Perhaps I'm misunderstanding something, but I'm not following your analysis. It looks like libwnck/libwnck/class-group.c:set_name() first calls get_name_from_applications(), which you describe as step (1). However, I don't understand what you claim as being tested for the group leader names. Because: get_name_from_applications() calls application.c:wnck_application_get_name() to get the name. (Then if all these are the same, it is used). wnck_application_get_name() return app->priv->name. app->priv->name is set by application.c:update_name(). update_name() has different behavior depending on whether there is one window in the group or more. With one window in the group, it sets the name to the return value of wnck_window_get_name(), which is ulimately set as you describe so I won't list the details of it. With more than one window in the group, the name is set via a call to _wnck_get_res_class_utf8, which returns the value of WM_CLASS. So, unless I'm misunderstanding (which it totally possible), for grouped windows _NET_WM_NAME is ignored and it doesn't matter if applications set a sane value for it. Also, apps should NOT set _NET_WM_VISIBLE_NAME (http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html#id2503578)
I'm not even sure those strings will help much. _NET_WM_NAME, at least, is the same as WM_NAME which is usually specific to each window.
I can't tell for sure, but I think there may be some confusion because the hints (_NET_WM_NAME, WM_NAME, etc.) are set on *both* the individual windows and on the group leader. When read from the group leader, they are supposed to be the name of the app (g_set_application_name()) and when set on an individual window they are the title for that window.
Elijah is right. libwnck/application.c:update_name() is just buggy. There seems to be some cruft in application.c --- see how _wnck_application_create() works; it takes a group leader (from screen.c), initializes the name of the WnckApplication to the group leader's name, and remembers that the name came from the group leader. However, the rest of the code doesn't pay attention to that flag anymore, except for reset_name().
Bumping version...
Moving to the right component. Sorry for the spam.
*** Bug 317305 has been marked as a duplicate of this bug. ***
Removing GNOME2.x target milestone for these bugs since this milestone hardly makes sense now.
*** Bug 325439 has been marked as a duplicate of this bug. ***
*** Bug 345350 has been marked as a duplicate of this bug. ***
It seems Elijah and Federico were misreading the code, since if the group leader has a name, then it's definitely what is used. I've added an assertion to make this clear :-) So this bug is really a bug in applications that don't use g_set_application_name().