GNOME Bugzilla – Bug 528927
aMSN windows do not flash taskbar anymore
Last modified: 2008-10-22 03:24:20 UTC
Please describe the problem: flashing message is sent by aMSN windows to Metacity via X through the linflash component (relevant code here: http://amsn.svn.sourceforge.net/viewvc/amsn/trunk/amsn/utils/linux/linflash/ ) Steps to reproduce: 1. open aMSN (I'm using SVN) 2. let someone call you with his/her contact window closed 3. the taskbar button won't flash Actual results: Expected results: Does this happen every time? it happens every time Other information: I've tested with OpenBox and it does work. My guess something might be broken in metacity; otherwise maybe we can understand what's wrong with aMSN's linflash
please notice at least since 2.21.8 and both with or without compositor
I can confirm this behavior using Ubuntu Hardy which uses metacity 2.22.0 Using compiz window manager, the panel 'flashing' works. As soon as i use metacity --replace, flashing stops instantly. I have filled this bug on launchpad too: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/220555 But i really think its a metacity bug, not in gnome. Have the standards regarding panel flashing changed between metacity 2.20 (which worked) and 2.21.x and later?
No, they haven't changed. Thanks. Can someone get this down to a reproducible small testcase? I don't know anything at all about MSN, and I don't know anyone who uses it as far as I know. (Although I suppose you folks must do, so perhaps otherwise we could arrange to be arround at the same time.) Giannis: 1) launchpad lets you sync GNOME bugs like this one with its bugs (I've done this for you) 2) "I really think its a metacity bug, not in gnome": any bug in Metacity is a bug in GNOME by definition, since Metacity is part of GNOME.
(In reply to comment #3) > Giannis: > 1) launchpad lets you sync GNOME bugs like this one with its bugs (I've done > this for you) > 2) "I really think its a metacity bug, not in gnome": any bug in Metacity is a > bug in GNOME by definition, since Metacity is part of GNOME. > Thank you for syncing the bugs with launchpad, didn't know about this feature. About the comment i made in my previous post, its a misstype. I wanted to say: "I really think its a metacity bug, not in *Ubuntu*" :) I have provided a small test case to reproduce this bug in the bug i filled at launchpad, i copy paste it here: ****************************** 1) On latest gnome - hardy and using metacity, install amsn from the repositories. (ubuntu hardy uses metacity 2.22.0 ) 2) Log in an have a friend talk to you and count from 1 to 20. 3) Minimize the contact window while your contact is talking 4) ---> The task bar entry of the minimised contact window does NOT blink. 5) run compiz --replace to enable compiz window manager 6) ---> Blinking / flashing works. 7) run metacity --replace now 8) ---> Blinking / flashing stops again. ******************************
Unfortunately I can't give more details than Giannis because I'm not myself into X programmng; the source code I linked should be straightforward for people dealing with Xorg like you because it is essentially a wrapper around Xorg functions providing a facility to Tcl/Tk programmers
I've forgot to add the aMSN followed strictly the FreeDesktops standard, and in fact it works with most WMs; my guess it's that unfortunately something got somehow broken in metacity
maybe I'm wrong; is metacity expecting that both DEMANDS_ATTENTION atom and URGENCY_HINT are set to the window for it to flash the taskbar? looks like aMSN uses only one of them alternatively at once
A simple testcase testing linflash is to do this (with aMSN and Tcl installed): wish load /usr/share/amsn/utils/linux/linflash/flash.so linflash . This should flash the taskbar button for the wish window that comes up. The source for linflash is at http://amsn.svn.sourceforge.net/viewvc/amsn/trunk/amsn/utils/linux/linflash/.
Some additions to this bug report. For starters, aMSN is a tcl program, and it uses 'linflash' for flashing to work on notifications. The files for linflash are here: svn co https://amsn.svn.sourceforge.net/svnroot/amsn/trunk/amsn/utils/linux/linflash/ You can grab flash.so that is needed from here: http://www.myprotia.gr/flash.so The good news are that you (metacity devs) can test without even amsn using the following procedure: (from inside the linflash folder): wish85 (it pops out an empty tcl window) (from inside the wish console): load flash.so (from inside the wish console): linflash . At this time the panel entry of the empty tcl window should start flashing until it gets focus. I have done some testing: ) KDE4 + kwin -> test works, we have flashing 2) KDE4 + kwin with builtin compositing effects enabled -> test works, we have flashing 3) KDE4 + compiz -> test works, we have flashing 4) KDE3 + kwin -> test works, we have flashing 5) KDE3 + compiz -> test works, we have flashing 6) GNOME + metacity 2.22.0 -> DOES NOT WORK -> there is NO flashing. 7) GNOME + metacity 2.22.0 with builtin compositing enabled -> DOES NOT WORK -> there is NO flashing. 8) GNOME + compiz -> test works, we have flashing Now we just have the linflash.c file and metacity 2.22 that dont like each other for some reason.. Any ideas welcome!
Instead of downloading flash.so you can compile it yourself with: gcc -I/usr/include/tcl8.5 -c -o flash.o flash.c gcc -shared -o flash.so flash.o inside the linflash folder you have from svn
Hello, I've discovered something interesting. I was working in a second workspace and received an amsn message. When I went back to the first workspace, the title was flashing. I am using ubuntu hardy.
confirmed comment #11 taskbar flashes if the window is on a different workspace
(In reply to comment #7) > maybe I'm wrong; is metacity expecting that both DEMANDS_ATTENTION atom and > URGENCY_HINT are set to the window for it to flash the taskbar? looks like aMSN > uses only one of them alternatively at once > It sure looks like it. If you comment out both line 135 and 137 (the if around setUrgencyHint) linflash behaves as expected. It seems to me that this should not be necessary, as it was not in the past.
From what you say, this will be an ideal thing to test with the testing architecture when it's ready.
I'm not sure if this problem is related, but it certainly seems to be, due to comment #11: If the window is on a different workspace and it is minimized, you will see it flashing on your taskbar in any other workspace; however, when you click on it, instead of unminimizing said window and going to the workspace in which it is, focus will shift to the previous window you were working on and the taskbar button will still be flashing. Since you can see the flashing button on the taskbar on any workspace, and in every one of them (except for the original desktop the window was on) it's effectively unclickable, you must either remember which workspace that window was originally in, or check all the desktops one by one to see where will the window unminimize. This problem happens of whether or not the patch suggested by comment #13 is applied, and I think it does happen on every flashing window - but I have no way to test that. If the window is unminimized on its own workspace, it will work as expected - clicking on the flashing button on the taskbar unminimizes it and takes me to its workspace.
Created attachment 120969 [details] [review] Fix demands attention This fixes the problem with aMSN as well as other applications that use demands attention.
I just tested, and I can confirm the patch above works beautifully.
Thanks; committed. I moved the check against "obscured" to the end to make the code a little more readable (not your fault!).