| Summary: | Windows set to start on other desktop still marked as requiring attention | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Romain <rlerallut> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | CC: | aseigo |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.9.0 | |
| Sentry Crash Report: | |||
|
Description
Romain
2010-03-23 13:24:09 UTC
is the Amarok entry in the tasks widget highlight? (aka it is "demanding attention") Yes, it is flashing slightly. In all cases, I have the "starting application" taskbar entry appearing (the one with the rotating wheel). Then, either of two things: 1. If Amarok displays its main window, then there is a flashing entry in the taskbar for all desktops (what I described in the bug entry). 2. If I have Amarok setup as "open only in the systray" (e.g. last time I closed the main window and then closed the app from the systray), then there is the "starting app" entry and then there is no Amarok entry even on the desktop where it appears. I hope I am making sense to you ! Romain (this is Amarok 2.3.1 on KDE 4.4.3) By the way, I noticed that if Amarok's main window is closed and I left click on the systray icon from a different desktop, then a flasing taskbar entry shows up (but the main Amarok window appears on desktop #2). If I click this taskbar entry then I'm transported to desktop #2. If I go back to my original desktop, then there is no problem. Oh, and the initial problem is not Amarok-specific, it happens also with e.g. KDE Space Duel. right, so the window is marked as "needing attention" (by the window manager in this case) and the panel is simply displaying that. windows marked as requiring attention are shown regardless of desktop because that is that entire purpose of that hint: to get the user's attention. perhaps kwin shouldn't be setting the attention state of the window in these cases? I can understand you reassigning to kwin, but not WONTFIX. Can you elaborate ? "Can you elaborate ?" when a window is marked as requiring attention, we show it. the window is marked as requiring attention. this isn't something that is going to change in the tasks widget. i can send this over to kwin if you wish, to see if they'll change the policy on which windows get marked as requiring attention. I doubt we can change the behavior without breaking the specifications. And it might be important to see that a window on a different desktop demands attention. Nevertheless I don't set the bug as wontfix and change to wishlist as it is perhaps possible to add a window rule to it. And with our scripting interface coming in 4.6 it should be possible to write a small JavaScript file which unsets the demands attention state if the app is Amarok and not on the current desktop. Git commit 9624be7fd5ebcbf53fceb99e0fc3e6035d36e620 by Martin Gräßlin. Committed on 14/03/2012 at 21:26. Pushed by graesslin into branch 'master'. New KWin example script: demands attention on current desktop The rational behind this script is to have only windows on current desktop as demanding attention. Restricting the demands attention state to the current desktop means for example that the tasks applet won't show windows started on different desktops. The script keeps track of the windows where it removed demands attention and restores the state when the window's desktop becomes active. A +79 -0 kwin/scripts/demandsattentioncurrentdesktop/contents/code/main.js A +17 -0 kwin/scripts/demandsattentioncurrentdesktop/metadata.desktop http://commits.kde.org/kdeexamples/9624be7fd5ebcbf53fceb99e0fc3e6035d36e620 Thanks to the script referenced in the comment above I consider this feature request as implemented in a worksforme state. Before 4.9 becomes available I will make the script properly available to be installed through get hot new stuff. |