GNOME Bugzilla – Bug 328211
Workaround for buggy application grouping (let transiency override separate group leaders for grouping)
Last modified: 2006-03-28 22:33:40 UTC
Metacity considers windows part of the same application if and only if they have the same group leader. XMMS sets a different group leader for its main window than it does for its playlist -- however, the playlist is marked as a transient of the main window. Seems like stupidity in XMMS, but it might be worthwhile having the transient property override separate group leaders. Not being able to identify these two windows as being part of the same application causes a real bug: If a user clicks on the main XMMS window, XMMS tries to raise its playlist window with a configure request; we detect that as a separate application tries to raise itself and deny it and set the demands-attention hint instead. Since the XMMS playlist window is marked as skip taskbar, this means that the user will most likely think "I click on this window and then its button in the taskbar starts blinking?!?". (Note that until I fixed a bug in libwnck recently, the blinking wouldn't actually start until the user switched workspaces and switched back) This is described in more detail in bug 317541 comment 7, along with two related libwnck bugs that were recently fixed.
So if I have XMMS and its playlist open and another window has the focus, and I click the XMMS main window, the XMMS button in the taskbar should start blinking? It doesn't happen for me.
What version of libwnck are you running with?
I'm not sure how to tell. I built metacity with "jhbuild build metacity" to get metacity's dependencies, and then did "cvs up -A" and "make" again. But now I see that jhbuild didn't check out libwnck, so I suppose it must have used the version in /usr/lib, which seems to be 1.4.9 :( I suppose what I need to do is check out libwnck, build it, and then pass details of that to metacity's configure?
libwnck isn't a dependency of metacity. It does interact with metacity, but it's just another module that had some related bugs. (Also, libwnck has only had versions less than 1.0 and greater than 2.0, so you can have a 1.4 version of it. If you're using your system version, the way to tell would be to query your rpm/deb/whatever packages to find out what version number it uses). Instead, if you're using an out of date version of libwnck, try following the steps in http://bugzilla.gnome.org/show_bug.cgi?id=317541#c7 to get the blinking. This bug report is about the metacity end of things and how blinking shouldn't happen at all. That other bug report was about libwnck not starting/stopping the blinking when told to do so until some time long after the event occurred.
Oh, thanks. It doesn't make a difference even if I switch workspaces away and back, though: 1. launch xmms, and the main window and playlist appear 2. click the xmms main window but not the playlist 3. switch to a different workspace 4. switch back The xmms button on the taskbar is selected but not flashing. Maybe I'm running the wrong version of xmms (1.2.10) or something? apt-cache tells me I'm running libwnck 2.8.1-3, fwiw.
Ahah, libwnck 2.8.1 is way too old; it had no support for demands-attention or urgent flashing at all. I think it was introduced for 2.12 or somewhere around that time.
Created attachment 59978 [details] [review] If A is transient for B, then see B as A's group leader Ah, that makes sense. I rebuilt gnome-panel with jhbuild, and ran that to replace the current one, but it didn't work even then. Is gnome-panel what produces the sequence of buttons along the bottom of the screen, or does it just do the panel? Here's something I wrote which at least compiles and runs, but I can't tell whether it fixes the problem until I can reproduce the problem :)
(In reply to comment #7) > Ah, that makes sense. I rebuilt gnome-panel with jhbuild, and ran that to > replace the current one, but it didn't work even then. Is gnome-panel what > produces the sequence of buttons along the bottom of the screen, or does it > just do the panel? Kind of. gnome-panel makes use of a lot of applets, most of them external to gnome-panel, but some which are built and distributed with gnome-panel. One of the applets distributed with gnome-panel is wnck-appelt, which is in charge of drawing those buttons. BUT, it uses libwnck (a separate library) to do most the work. To duplicate this bug, you need to have a newer libwnck.
Well, last night I dist-upgraded to sid, and now my distribution's copy of metacity exhibits this bug. Hooray! So I tried it with the patch in attachment 59978 [details] [review]. The problem appears to go away with it applied, and come back when it's not, so I guess the patch does do what I intended.
The patch looks good. I had been thinking of an alternate way to handle it, by modifying meta_window_same_application(), but I like the method you chose better.
Committed, thanks!
There was a bug in this patch that I didn't catch; see bug 336184 for details.