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