GNOME Bugzilla – Bug 76159
Change window grouping to be based on window class
Last modified: 2004-12-22 21:47:04 UTC
Emacs is never grouped in my window list-- so i have say, 3 windows for gaim, represented by a single space in my menu-list, but four terminals represented by four items, and three emacs windows represented by three individual items. This is despite saying "Always Group Windows"
The grouping is by application - Emacs deliberately makes each toplevel window appear to be a separate application. Don't ask me why, they had to go out of their way to do this. Terminals will appear as a single app once we have the "factory" feature . For now if you use "new window" instead of launching new terminals, they will come up as a single app.
Well, it worked for emacs in gnome 1.4. :( I'll file a bug against emacs then... any information in particular that I should give them?
1.4 is grouping based on window class, rather than based on applications. It's possible we should change how the grouping is done. I'm just saying that it is currently working as intended.
Now that I've read the comments I understand what is meant by the grouping. I was expecting the grouping to work like 1.4.x. Maybe the options should be labelled "group application windows" instead of just windows.
honestly, I think grouping should work like it does in 1.4. I'd even go further, and suggest that all windows associated with an application should get the same treatment: both Evolution and the Evolution mail composer windows shoudl fall under the same group, all emacs buffers should fall under the same group, as should all terminals. IMHO, this just makes better sense.
*** Bug 77967 has been marked as a duplicate of this bug. ***
*** Bug 85475 has been marked as a duplicate of this bug. ***
*** Bug 79073 has been marked as a duplicate of this bug. ***
*** Bug 90828 has been marked as a duplicate of this bug. ***
*** Bug 96951 has been marked as a duplicate of this bug. ***
*** Bug 111836 has been marked as a duplicate of this bug. ***
I agree, the 1.4 behavior was much nicer... when I open 20 windows with nedit they are not grouped, so I want to close all the windows they must be done manually instead of right-click->close all
*** Bug 120559 has been marked as a duplicate of this bug. ***
The problem is that libwnck considers window groups to be based on the group leader of windows, rather than the res_class of the WM_CLASS hint. GNOME 1.4 does a simple g_strcasecmp() on the res_class to group windows; libwnck in GNOME 2.0 uses the group leader's xid. I have no idea of why Emacs uses a different group leader for each frame. I'm taking care, of this, so I'll reassign it to myself.
> The problem is that libwnck considers window groups to be based on the > group leader of windows Window groups _are_ based on that. ;-) Window class doesn't define a window group, it defines a kind of window for purposes of applying xrdb configuration. The group leader is supposed to indicate a main window and associated windows. The basic misconception leading to the current libwnck behavior I think was the same one GTK has - that every window in the same application should share a group leader. Given GTK apps, the group leader is more reliable as various windows in an app can have all kinds of random resource classes. Emacs does the right thing by having a separate group leader per toplevel, so that is why libwnck (and GTK) are broken.
Even if emacs did something different with group leaders, it wouldn't help me, because I never open more than one emacs "frame" per process. But I often have 6+ emacsen running, each on a different host via ssh-tunnelled X. So it would be impossible for them to share a group leader in any case. They should still all to be grouped together on the panel task-list menus, though.
Sure, I agree with that.
The following patch fixes the problem, but still has some cosmetic issues discused in http://mail.gnome.org/archives/desktop-devel-list/2003-September/msg00890.html Havoc, do you have time to take a look? Thanks! :)
Created attachment 20420 [details] [review] Patch that fixes the problem.
Created attachment 20458 [details] [review] New version of the patch; fixes the problems discussed on desktop-devel-list.
+ /* Class group */ + + xid = wnck_window_get_xid (window); do you ever use this xid? + if (!app || g_utf8_collate (first_name, wnck_application_get_name (app)) != 0) + break; strcmp() should be fine to test equality, no need to utf8_collate which is slow. (same comment for the two other uses of it) Still not happy about the for() loops but if you make a tarball or two I'll forgive you. ;-) Feel free to commit.
*** Bug 97569 has been marked as a duplicate of this bug. ***
*** Bug 96067 has been marked as a duplicate of this bug. ***
Federico, did you have time to look at Havoc's comments?
Committed an updated version to the gnome-2-2 and HEAD branches. W00t.
I had forgotten to commit this to the gnome-2-4 branch; it's in now as well.
Thank you for fixing this! I just upgraded to a version that includes the fix, and it's like that feeling when your ears have been clogged all day and then suddenly they clear and you can hear again.