GNOME Bugzilla – Bug 317541
XMMS randomly blinks, and activating the window(s) doesn't stop the blinking
Last modified: 2006-02-11 10:17:39 UTC
Please describe the problem: Hi. In gnome 2.12 the taskbar has a new blinking feature. It has a few problems: 1. sometimes the tasbar button corresponding to some window starts blinking even if the window is active. This seems unnecessary. Also, the only way to stop the blinking is to click the title bar. This is not intuitive. (note: clicking the taskbar button minimizes the window.) 2. in addition, for some programs (e.g. xmms), the blinking is impossible to stop, even clicking the titlebar. The only way to stop it is to kill the application. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Movint to libwnck.
Exact steps to reproduce? Also, libwnck just blinks windows when either Metacity tells them to, or the app itself tells it to, so it really isn't a bug with the taskbar. We'd need to know the exact steps to reproduce to figure out who's fault it is, though...
> Also, libwnck just blinks windows when either > Metacity tells them to, or the app itself tells it to, libwnck blinks whenever the app requests it? Then this is the problem. If an app requests a blink, libwnck should accept the request ONLY if the app is not focused (=not active). That is what Windows and KDE do, and what makes sense. Otherwise you have the following problem. Messaging apps (kopete, gaim...) send a blink signal for each new message that is typed by the remote interlocutor. As you said, libwnck always fulfills the request (even if the kopete window is focused). The kopete window starts blinking and the only way to stop it is to click the _titlebar_ (clicking the taskbar button won't work.) So this was a way to reproduce the first problem: do a chat. :-) For the second problem (the xmms taskbar button starts blinking and is impossible to stop), I haven't been able to reproduce it. It seems unlikely to me that xmms requests a blink, so it must be metacity who requests a blinking for xmms. However, it happens. And when it happens, the only way to stop the blinking is to kill xmms.
We could probably have window activation shut the blinking off within libwnck; sounds sane. Not a metacity bug, though.
Reopening too...
Sorry for the spam--it seems we could also stop the blinking upon mouse hover...
BUGGGGGGY! Okay, I ran across it myself too and figure out how to reproduce and noticed a few problems. First, to reproduce: 1. Open xmms 2. Make sure the playlist window is showing 3. Click on the main xmms window (not the playlist) 4. Do NOT focus the playlist (if in sloppy/focus modes, do not move the mouse over the playlist window) 5. Switch workspaces 6. Switch back At this point, the xmms button in the taskbar will be blinking--not because the xmms window demands attention, but because the playlist window (which is a transient) does. Now, do the following: 7. Focus the playlist window (click on it, or just move the mouse over it if in sloppy/mouse focuse modes). 8. Switch workspaces 9. Switch back At this point, the button in the taskbar for xmms will no longer be blinking. There are two-three bugs at play here: A) Metacity doesn't notice that the playlist window is in the same "group" (metacity meaning of group which attempts to approximate "same application", not libwnck's meaning of group) as the main xmms window--if it had noticed, it wouldn't have set the demands attention hint. B) Libwnck doesn't notice when the demands attention hint is set on the transient at first--the button in the taskbar should have started blinking right at step 3 given bug A. C) Libwnck doesn't notice when the demands attention hint is removed from the transient at first--the button in the taskbar should have stopped blinking right at step 7. It may also be worthwhile to stop taskbar blinking if the task becomes active or the mouse hovers over the task in the panel, but A-C are the real bugs.
Good job. > It may also be worthwhile to stop taskbar blinking if the task becomes active Indeed. If the task is active, it already has my attention. So blinking seems useless and can only be disturbing. While chatting, this problem is noticeable, forcing me to click the title bar each time my friend types a message.
Created attachment 57864 [details] [review] Fix libwnck to update visible state of ancestors when needed This fixes (B) and (C) from comment 7. (A) is a metacity bug (well, actually it looks more like an XMMS bug, but perhaps one we should work around) so I'll file a separate bug for it. It turns out that because of the fix from bug 163293, this was surprisingly rather easy to fix.
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/libwnck/+bug/31134