Created attachment 125581 [details] Video demo SUMMARY Sometimes apps set their window _NET_WM_STATE to _NET_WM_STATE_DEMANDS_ATTENTION. Depending on each latte instance's configuration, the user-configured visibility policy is violated to different degrees. This can be impractical and annoying. STEPS TO REPRODUCE 1. create a latte panel with the Task Manager widget 2. set its visibility policy to Dodge Active 3. in konsole, `xprop -id $WINDOWID -f _NET_WM_STATE 32a -set _NET_WM_STATE _NET_WM_STATE_DEMANDS_ATTENTION` OBSERVED RESULT It is now impossible to get the panel to hide, without changing the window state (`xprop -id $WINDOWID -f _NET_WM_STATE 32a -remove _NET_WM_STATE`) EXPECTED RESULT Either: - only raise the panel in violation of visibility policy for a short time - don't raise the panel in violation of visibility policy - add a toggle-able option to each latte instance to obey visibility policy even when windows have this state SOFTWARE/OS VERSIONS Linux: Arch KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1
It is already set to be shown for just 20secs if I remember correctly. The fact that an application has set that flag it means that wants the attention. It has already been discussed also for plasma panels and taskmanagers and they concluded that this is the best approach.
It does not resume user-set visibility behavior after 20 seconds, or 60 seconds, and I'm not sure if it ever does, with the configuration described. Even if it did, 20s is an eternity if I'm trying to do work in an area that's suddenly covered.
just checked ... it is set to 8,5 secs and you find that too much?
(In reply to Michail Vourlakos from comment #3) > just checked ... it is set to 8,5 secs and you find that too much? Whatever it's 'set' to, it's *behavior* is AFAICT actually 'forever'. I find 'forever' too much, certainly. I would prefer shorter than 8.5s, but that would be a big improvement.
BTW I also checked plasma taskmanagers, their design decision is that they never stop... so as long a window has set INATTENTION flag the plasma panels are shown without being able to hide at all.
(In reply to andydecleyre from comment #4) > (In reply to Michail Vourlakos from comment #3) > > just checked ... it is set to 8,5 secs and you find that too much? > > Whatever it's 'set' to, it's *behavior* is AFAICT actually 'forever'. I find > 'forever' too much, certainly. > > I would prefer shorter than 8.5s, but that would be a big improvement. it is already set to 8.5 secs.
(In reply to Michail Vourlakos from comment #6) > it is already set to 8.5 secs. I feel like we are having a miscommunication. As described in the report, and comments 2 and 4, it is NOT hiding after 8.5s, or indeed ever.
(In reply to Michail Vourlakos from comment #1) > The > fact that an application has set that flag it means that wants the > attention. Further, the current behavior can *obscure* the window that wants attention, as is demonstrated in the originally attached video. This bugzilla instance fails at properly sharing the attachment, but if you download it, you can see the video, which is not "corrupt" as bugzilla claims.
I won't add any option for this. On the other hand if the Needs Attention never stops then this is a bug, and I would need steps to reproduce because in my system works just fine, after 8.5 secs the in question dock becomes hidden again.
(In reply to Michail Vourlakos from comment #9) > I won't add any option for this. On the other hand if the Needs Attention > never stops then this is a bug, and I would need steps to reproduce because > in my system works just fine, after 8.5 secs the in question dock becomes > hidden again. Ok, if you have already tried the originally posted reproduction steps exactly and it didn't reproduce the problem, I will upload a configuration and layout when I'm back at a computer.
Alright, I created a fresh user, a fresh latte dock, and configured exactly as described in the original post: Task Manager widget and Dodge Active set, with no other items. Then I tested exactly as described in the original post, with xprop. I am attaching the lattedockrc, layout config, and a screenshot showing how the "needs attention window" (konsole) is obscured by latte. This never seems to end, at least with a few minutes of waiting. I honestly have a hard time believing that you have actually followed the reproduction steps and still not reproduced the issue.
Created attachment 125647 [details] Screenshot of nearly vanilla setup exhibiting the problem
Created attachment 125648 [details] nearly vanilla lattedockrc exhibiting the problem
Created attachment 125649 [details] nearly vanilla layout exhibiting the problem
(In reply to andydecleyre from comment #11) > I honestly have a hard time believing that you have actually followed the > reproduction steps and still not reproduced the issue. believe it. I have set the dock to AutoHide to be even from obvious what is happenig. In my system, 1. Set a Latte dock to Auto hide 2. run your first command for a window 3. dock shows just fine for 8 secs and hides itself afterwards even though the window has not lost the needsattention flag 4. reexecuting [2] has no point because the window is still in NEEDSATTENTION 5. clearing its needs attention with your second command and reexecuting [2] behaves as normally from [3] Have you tried master version?
Ok, found it but this is NOT LATTE responsibility... Things work just fine with Latte Tasks plasmoid ! BUT you are using a Plasma Taskmanager. The Plasma Taskmanager sets its status to NEEDSATTENTION and in such case Latte responds to always SHOW the Latte dock/panel because it is AN APPLET requesting ATTENTION and in such case there could be no timer... Only solution for you is either to request from plasma devs that behavior with a timer or you need to switch to Latte Tasks, but I suppose this is not something you would prefer.
I will try master now. But to be sure: you're trying with - panel mode - plasma Task Manager right?
So you had not been following the reproduction steps until now. Does latte tasks support ungrouped, text-based task items? I will change the product for this bug to Task Manager. Thank you for reproducing.
(In reply to andydecleyre from comment #18) > So you had not been following the reproduction steps until now. Does latte > tasks support ungrouped, text-based task items? > > I will change the product for this bug to Task Manager. Thank you for > reproducing. OH I did but you never mentioned you are using a Plasma taskmanager, only by using your layout file that was obvious...
(In reply to Michail Vourlakos from comment #19) > (In reply to andydecleyre from comment #18) > > So you had not been following the reproduction steps until now. Does latte > > tasks support ungrouped, text-based task items? > > > > I will change the product for this bug to Task Manager. Thank you for > > reproducing. > > OH I did but you never mentioned you are using a Plasma taskmanager, only by > using your layout file that was obvious... "with the Task Manager widget" -- original report.
This has been maddening, every time I open a chat app, especially Konversation. But I've finally worked around it, in case anyone else has the same madness. I just removed the NeedsAttentionStatus possibility from the plasmoid altogether. In /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml : Binding { target: plasmoid property: "status" /* value: (tasksModel.anyTaskDemandsAttention ? PlasmaCore.Types.NeedsAttentionStatus : PlasmaCore.Types.PassiveStatus) */ value: (PlasmaCore.Types.PassiveStatus) } Otherwise the window I'm actively working in will be indefinitely obscured by the panel, until I disrupt my workflow to find and appease whichever window is demanding attention, even if that window is the window I'm already focused on.
As I'm applying my workaround after each release, here's a handy regex replace command using sd, in case anyone else struggles with the current behavior: sd 'value: \(tasksModel\.anyTaskDemandsAttention\n.*' 'value: (PlasmaCore.Types.PassiveStatus)' /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml
*** This bug has been marked as a duplicate of bug 394119 ***