User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.2pre) Gecko/20061023 SUSE/2.0.0.1-0.1 Firefox/2.0.0.2pre Build Identifier: _NET_WM_STATE_DEMANDS_ATTENTION doesn't work as expected. I would expect the same behaviour as for the urgent hint. Currently it only works if you with to another desktop and back, then the taskbar entry blinks. Reproducible: Always Steps to Reproduce: 1. Download http://www.bwalle.de/temp/attention_test.tar.bz2 2. tar xvfz attention_test.tar.bz2 3. cd attention_test 4. cd srcmoc -o main.moc main.cpp 5. cd - 6. make -f admin/Makefile.common 7. ./configure 8. make 9. src/test 10. focus another application 11. you should see 'flashing' in the console, and now the hint is set and the panel entry should flash 5. Actual Results: See 'details' Expected Results: Flashing :)
As far as I can see they are treated exactly the same. I was wondering if perhaps the window manager removes the hint when the window is visible. Olivier, do you have an idea about what could be happening?
NET_WM_STATE_DEMANDS_ATTENTION is removed as soon as the window is focused. From the spec: [1] "_NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or with the window happened. For example, it may be set by the Window Manager if the window requested activation but the Window Manager refused it, or the application may set it if it finished some work. This state may be set by both the Client and the Window Manager. It should be unset by the Window Manager when it decides the window got the required attention (usually, that it got activated)." [1] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html
Of course, but here it isn't focused before and it doesn't blink. It only blinks if I switch to another workspace and back.
Should be fixed with rev. 24174.
Thanks, works. Is it intended that the 'Window list' doesn't blink as for WM_URGENT?
There must be something wrong with the fix. Now taskbar entries of windows (e.g. Terminal) flash that never have set the urgent or "needs attention" flag.
The window manager can set NET_WM_STATE_DEMANDS_ATTENTION if focus stealing prevention is triggered, as it is the case with terminal. I see nothing wrong with the patch.
> Is it intended that the 'Window list' doesn't blink as for WM_URGENT? Urgency and NET_WM_STATE_DEMANDS_ATTENTION are different things.
(In reply to comment #7) > The window manager can set NET_WM_STATE_DEMANDS_ATTENTION if focus stealing > prevention is triggered, as it is the case with terminal. I see nothing wrong > with the patch. I didn't enable focus stealing prevention in the settings. Here it simply occurs if I show + hide kopete (or another Qt application that has a systray icon) via systray icon. So to reproduce: 1. Open Kopete and hide it to systray. 2. Open Terminal or Firefox or something else. 3. Click on systray icon -> shows kopete window 4. Klick again on systray icon -> hides Kopete window 5. _Now_ the Firefox (that is already focused!) blinks, I have to klick into Firefox to disable blinking It doesn't make sense to show _NET_WM_STATE_DEMANDS_ATTENTION on an application that already has the focus. And typing doesn't help, I need to click in the window to disable it.
(In reply to comment #8) > > Is it intended that the 'Window list' doesn't blink as for WM_URGENT? > > Urgency and NET_WM_STATE_DEMANDS_ATTENTION are different things. ok. Just wondered because the comment from Jasper said that they are handled the same way. ;)
The problem with kopete and demands attention should be fixed with rev. 24177.
(In reply to comment #11) > The problem with kopete and demands attention should be fixed with rev. 24177. Confirmed. Thanks. And have a nice Christmas.
(In reply to comment #12) > Confirmed. Thanks. And have a nice Christmas. Thanks, you too ;)
Again, I discovered another issue with _NET_WM_STATE_DEMANDS_ATTENTION. If an application sets this flag while it already has the focus, wouldn't it make sense to reset _NET_WM_STATE_DEMANDS_ATTENTION after changing the focus from this application to another application? Ok, we can discuss if that makes much sense, but Kopete does this and it's quite annoying. kwin seems to ignore _NET_WM_STATE_DEMANDS_ATTENTION if a client has the focus.
Ok, rev. 24223. but it sounds a bit like a workaround for broken apps.