After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 76159 - Change window grouping to be based on window class
Change window grouping to be based on window class
Status: RESOLVED FIXED
Product: libwnck
Classification: Core
Component: general
0.x
Other Linux
: Normal normal
: GNOME2.x
Assigned To: Federico Mena Quintero
Havoc Pennington
: 77967 79073 85475 90828 96067 96951 97569 111836 120559 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-03-24 21:59 UTC by aaron
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that fixes the problem. (49.62 KB, patch)
2003-10-01 22:42 UTC, Federico Mena Quintero
none Details | Review
New version of the patch; fixes the problems discussed on desktop-devel-list. (63.07 KB, patch)
2003-10-03 23:14 UTC, Federico Mena Quintero
none Details | Review

Description aaron 2002-03-24 21:59:49 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"
Comment 1 Havoc Pennington 2002-03-27 16:51:26 UTC
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.
Comment 2 aaron 2002-03-27 16:54:54 UTC
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?
Comment 3 Havoc Pennington 2002-03-27 17:10:05 UTC
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.
Comment 4 Ross Burton 2002-04-01 18:57:54 UTC
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.
Comment 5 aaron 2002-04-01 22:56:38 UTC
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.
Comment 6 Havoc Pennington 2002-05-13 21:42:56 UTC
*** Bug 77967 has been marked as a duplicate of this bug. ***
Comment 7 Luis Villa 2002-08-06 23:52:36 UTC
*** Bug 85475 has been marked as a duplicate of this bug. ***
Comment 8 Havoc Pennington 2002-09-16 21:07:05 UTC
*** Bug 79073 has been marked as a duplicate of this bug. ***
Comment 9 Havoc Pennington 2002-09-17 18:01:06 UTC
*** Bug 90828 has been marked as a duplicate of this bug. ***
Comment 10 Havoc Pennington 2002-10-27 14:50:32 UTC
*** Bug 96951 has been marked as a duplicate of this bug. ***
Comment 11 Havoc Pennington 2003-04-29 16:33:33 UTC
*** Bug 111836 has been marked as a duplicate of this bug. ***
Comment 12 Monte Ohrt 2003-06-17 16:49:04 UTC
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
Comment 13 Havoc Pennington 2003-08-25 14:14:36 UTC
*** Bug 120559 has been marked as a duplicate of this bug. ***
Comment 14 Federico Mena Quintero 2003-09-22 05:49:27 UTC
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.
Comment 15 Havoc Pennington 2003-09-22 16:23:33 UTC
> 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.
Comment 16 Jamie Zawinski 2003-09-22 18:28:04 UTC
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.
Comment 17 Havoc Pennington 2003-09-22 19:57:37 UTC
Sure, I agree with that.
Comment 18 Federico Mena Quintero 2003-10-01 22:41:48 UTC
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! :)
Comment 19 Federico Mena Quintero 2003-10-01 22:42:21 UTC
Created attachment 20420 [details] [review]
Patch that fixes the problem.
Comment 20 Federico Mena Quintero 2003-10-03 23:14:49 UTC
Created attachment 20458 [details] [review]
New version of the patch; fixes the problems discussed on desktop-devel-list.
Comment 21 Havoc Pennington 2003-10-15 20:32:01 UTC
+	  /* 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.

Comment 22 Vincent Untz 2003-10-20 09:31:56 UTC
*** Bug 97569 has been marked as a duplicate of this bug. ***
Comment 23 Vincent Untz 2003-10-20 09:32:42 UTC
*** Bug 96067 has been marked as a duplicate of this bug. ***
Comment 24 Kjartan Maraas 2003-10-30 21:22:58 UTC
Federico, did you have time to look at Havoc's comments?
Comment 25 Federico Mena Quintero 2003-11-22 23:50:17 UTC
Committed an updated version to the gnome-2-2 and HEAD branches.  W00t.
Comment 26 Federico Mena Quintero 2003-11-28 19:14:54 UTC
I had forgotten to commit this to the gnome-2-4 branch; it's in now as
well.
Comment 27 Jamie Zawinski 2003-11-30 00:53:11 UTC
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.