Version: (using Devel) Installed from: Compiled sources marking taskbar entry does not work in KDE3 it simply worked, taskbar entry flashed, in KDE4 -- nothing. With this notification only user is not able to say if there was notification sent at all.
*** Bug 165722 has been marked as a duplicate of this bug. ***
works in svn, don't remember exactly in what revision it was implemented
No, it does not. You can check this easily, konsole -> notification -> beep -> popup + mark entry Then type konq and press tab key. Popup will appear but the taskbar entry will not flash.
hmm, could be a konsole bug? or could it be some ways that doesn't catc all notifications? for other apps like konversation it works
I don't have that app and the only one I found with notifications is akregator. In akr. nothing works. So it is hard to compare.
easy way to check: start kwrite on desktop 1. type something into the window. switch to desktop 2. right click on its taskbar entry and select "Close". this will cause a close-without-saving warning dialog to appear on desktop 1 and the taskbar entry to blink. btw, this is almost certainly either a konsole or a knotify bug.
It blinked.
It seems that it doesn't blink for konsole because konsole is the currently active application - and it's already highlighted in a task bar. I don't know if this is a bug or if this is a feature :)
It is a bug, I could work in another tab (and that's why there are two entries for such cases).
Much time spent with xprop -spy shows that konsole isn't, in fact, setting the _NET_WM_STATE_DEMANDS_ATTENTION atom, and so isn't telling plasma that the taskbar should be changed in any way. I can't get it to set that atom whether the window has focus or not. Regardless, this isn't a plasma issue, but a konsole (or, more likely, a knotify) one. Reassigning to Konsole, but it might yet get moved to KNotify.
Lubos: you assigned this bug back to plasma, but with no explanation. Can you elaborate, please?
Created attachment 28520 [details] testapp Comment #8: That is a feature. Applications cannot demand attention while active, since they already have all the attention they can get. I don't think the other-tab argument holds - in such case the inactive tab should do be marked somehow, like e.g. in irc clients. This testcase works in KDE3 with KWin from KDE4 running, so the bug should be neither in KWin nor in the libraries (and you can check if Plasma works).
When I run k3b to burn disc, or run computation, or "wait" for new mail I will like to be informed about this event without doing any extra gymnastic (making app inactive) and worrying that maybe I forgot to switch the app. However I see that there might me also a demand for non-interactive notification, so it is better to be left up to the app & user to set the required mode or event. Underlying mechanism should fire notification always, as the app set it.
ok, so this is an intention feature. fair enough, and reasonable. i think Lubos' reasoning is accurate ont his one.
By this wontfix you are cutting all apps from the notifications! It should be up to application to set the notification if it is active/inactive (pretty much as the konsole with tabs). The suggested behaviour is that user set notification _once_ and KDE takes the rest, not that user has to make it inactive _every time_ because KDE hardcoded behaviour is cutting off active apps.
> By this wontfix you are cutting all apps from the notifications! all apps? please. > The suggested behaviour yes, i read the bug entry, including everyone's comments, and made a decision.
Yes, all apps. If underlying algorithm checks if the app is active or not, there is no way, the notification is passed. For any app.