| Summary: | Panel should not stop auto-hiding even when a window wants attention | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | triffid.hunter |
| Component: | Panel | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | wishlist | CC: | 0456523, andydecleyre, barrowes, bkorb, h.klene, jan, kde-bugs, kde, lucian303, maikcrew, mzanetti, nate, rafneq, ville.aakko |
| Priority: | HI | Keywords: | regression |
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=435095 | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-desktop/commit/6779cfc8b11cee069833748600ceeabab1f791d5 | Version Fixed In: | 5.22 |
| Bug Depends on: | |||
| Bug Blocks: | 406857 | ||
| Attachments: |
Patch to prevent panel un-hiding when a window wants attention
patch to prevent Task Manager wanting attention if an app's window sets the flag Add the option to prevent Task Manager unhiding panels when a window wants attention Add the option to prevent Task Manager unhiding panels when a window wants attention Add the option to prevent Task Manager unhiding panels when a window wants attention |
||
Thanks for the patch! These tend to get lost when they're just attached to Bugzilla tickets, so I encourage you to formally submit it using Phabricator: http://phabricator.kde.org/ The documentation for how to do this is located at https://community.kde.org/Infrastructure/Phabricator I'll be happy to give you a hand. Even if this patch won't be accepted as-is, by submitting it, you can start a conversation with the developers regarding what might be a better way. I anticipate that you'll run into conceptual objections: if panels don't show when a window or app wants attention, how are you supposed to find that out except by chance, the next time you happen to show the panel? In the end, a configuration option might be needed. P.S. what's your favorite 3D printer these days? https://phabricator.kde.org/D12916 wow, that's the most complicated patch submission process I've ever experienced! Thanks for the patch! Hopefully the web form wasn't too bad... It's basically: 1. Generate a diff 2. Paste it into the form Can you give some more background on your specific situation. Patch as-is definitley isn't oging in, it'll break way too much, but there's a few options on what the best approach forward is. Is it your primary panel? Which app keeps becoming needs attention any why? Does it have any other alternative notification? Any issues with SNIs being marked as needsattention? (from within plasma I think that's only the battery when on <15% power) Yes it's my primary and only panel. Firefox "wants attention" any time I move the mouse off it without one mouse event position being on the border (ie if I move the mouse quickly), no idea why. Also konsole and kvirc often want attention as do various other apps. I don't know what a SNI is, but this is on a desktop and the only battery notifications are for my mouse, which goes for about a year on one battery so popup notifications for that aren't a problem. I wouldn't mind at all if the panel popped out for a few seconds when something wanted attention, or even stayed out until I mouseover-mouseoff (which worked in kde4) - but having the panel remain visible until I focus every single thing that wants attention is extremely irritating. The whole reason I want it to autohide is so I can have more uncluttered desktop space, and as I don't use the panel that often, having it jump out and *cover things* until I've well and truly interrupted my workflow is a big problem for me. The attached patch has quite completely solved my issue, although I completely understand that it's not the correct solution and states as much in my first post :) Perhaps I'll keep it in my local patch list until I (or someone) works out a more acceptable/generic way to fix this. I'm suffering from this as well, mostly because of Thunderbird or Pidgin demanding attention. I hide my panel because I want to focus and not get drawn away from my current task by "hey you have a new email" notifications, so it's somewhat counterproductive now. I wouldn't mind the option to completely disable the attention-seeking of tasks, if that's easier to implement than its influence on panel-hiding. Happens here too. In my case it's not a single application that can be blamed. It's rather regular things that cause the panel to pop in (regular notifications which I do want to see). The issue is more that just because a notification comes in, it doesn't imply that I want to immediately act on it. The panel popping in then covers part of the application I'm working with and I need to switch app and back just to mark that event as "seen" and continue my work. IMHO the panel should always auto-hide again, there is no reason why anything should prevent it from hiding again except the mouse hovering it. Actually I even think the panel should never auto-show unless I push the mouse to the border (or invoke it explicitly with the keyboard). Such highlights would be better implemented by adding a glow to the edge or something. It happens too often that I want to click something and just that moment the panel pops in and I click on the panel instead... Atm I even disabled panel autohiding completely and just shrunk it to a size which wouldn't take away too much screen space to work around this issue. Hi, I want to add here some voice / opinions about the current situation. Current behaviour is very conterproductive in my use case. I use my main panel as a kind of menu and information panel I want to see if and only if I want to,. But there are some applications I use, which just want attention, but I have no idea *why* do they want it. In any case, they force the panel to stay unhidden until I visit those applications windows. For example, every time I need to log in, there are 1-3 application windows which want attention for whatever reason. The panel will not autohide untill I cycle trough all of the application windows once. The same situation pops up every now and then while using the desktop. I believe there are different use cases here; some users want panels as some kind of intelligent/persistent notifier for pending tasks, which will autohide only if there is nothing in the work queue. Others want to check it if and only if they want to. I fall into this latter category. All in all I feel there should be a more simple autohide option; it should always autohide no matter what wants attention. As a sidenote, IMHO notifications should never be persistent on the screen; if there are notifications, they should be perhaps popups which will stop nagging in, say, in a timeframe of 2-10seconds. Current way of notifying (preventing autohide) of attention-seeking applications seems very odd and conterproductive. I agree!! Hiding panel do not work corectly. It is horrible! The worst thing is when you type in LibreOffice and mark it. Then use the mouse to navigate to the status bar to select a different language. Unfortunately, it happens a lot of times that I go down and show me a hidden panel that can't disappear. So I have to click and decorate the LO header and mark the text again. Also, in Firefox it often happens that the panel doesn't hide. I use Manjaro 18 with Plasma 5.15.4 and does Kubuntu 18.04 with Plasma 5.12. Since this bug is coming up on a year old, thought I'd chime in again. I still have the attached patch in my local patchset, and it seems to apply cleanly against plasma-workspace-5.14.5.1. I haven't noticed any adverse behaviour as a result; in fact my panel now works exactly how I want it to. *** Bug 406857 has been marked as a duplicate of this bug. *** So let me get this straight. The *intended* behavior is that I click on every single window that demands attention each time it does so that autohide works? So every Whatsapp, Slack, Signal, Keybase message that comes in I have to switch to it to hide the panel> Every time FF or other app starts up I need to stop what I'm doing and click through these things? The whole point of having autohide is to remove distractions. This creates distractions. Look at the OSX toolbar. It autohides and doesn't pop up for a millisecond when u have notices. Same thing with Windows. You can see what notices you have when you unhide it with the mouse. That's the whole reason for autohiding. At the very least there should be an option to not show it when apps demand attention. It should be up to the user not the apps to show the panel. Sometimes apps like FF and PHPStorm demand attention for no reason just because they're starting up. I just get the dots and the panel is visible and I have to click on it and get distracted, and then try to get back to work. It took me two weeks simply to understand what was happening. At first I thought it was just random (also because the dots indicating an app wants attention are almost invisible). No desktop environment I have ever used does what this panel does. It's neither intuitive nor expected. This UX is beyond bizarre and frankly, unusable. (In reply to lucian303 from comment #12) > So let me get this straight. The *intended* behavior is that I click on > every single window that demands attention each time it does so that > autohide works? So every Whatsapp, Slack, Signal, Keybase message that comes > in I have to switch to it to hide the panel> Every time FF or other app > starts up I need to stop what I'm doing and click through these things? The > whole point of having autohide is to remove distractions. This creates > distractions. Look at the OSX toolbar. It autohides and doesn't pop up for a > millisecond when u have notices. Same thing with Windows. You can see what > notices you have when you unhide it with the mouse. That's the whole reason > for autohiding. At the very least there should be an option to not show it > when apps demand attention. It should be up to the user not the apps to show > the panel. Sometimes apps like FF and PHPStorm demand attention for no > reason just because they're starting up. I just get the dots and the panel > is visible and I have to click on it and get distracted, and then try to > get back to work. It took me two weeks simply to understand what was > happening. At first I thought it was just random (also because the dots > indicating an app wants attention are almost invisible). No desktop > environment I have ever used does what this panel does. It's neither > intuitive nor expected. This UX is beyond bizarre and frankly, unusable. Now, I agree with pretty much you are saying here. I'd still like to remind you that we're all supposed to be friends here and be nice to each other :). I also understand that's hard at times, because, I also agree this bug can be so annoying that it makes one angry when it's interrupting a focus demanding workflow. @triffid.hunger, after reading the review comments from David on your patch, I understand your patch will prevent all plasmoids from popping up, not just the panel. I can understand that this is not a solution that will be accepted upstream. Do you think you could try and fix this in a way that could be accepted upstream? I haven't experienced the issue since adding my comment #1 patch into my local patchset, and I'm not even slightly familiar with KDE/QT programming.. Care to offer any pointers for more suitable places to put it? Since it alters a file called 'panelview.cpp' and specifically ignores 'NeedsAttentionStatus', I haven't currently any better ideas. I guess for best results, a user setting would need to be added to panel config that controls whether or not 'NeedsAttentionStatus' is ignored wrt panel hiding? That's a little beyond my skill currently but perhaps I can have a dig when I've some time and try to work it out - unless one of these other infuriated folk beat me to it ;) I'm not really sure what the point about 'other plasmoids' is, the panel is basically the only thing I have with widgets and I don't use it that often, so I'm not sure if I'd even notice if I inadvertently break these 'other plasmoids'.. So, to recap: I believe there are actually two parts to the problem here; 1) An application wanting attention, causing *task manager* to want attention, and 2) the way any auto-hide enabled panels behave when *any plasmoid* in them wants attention (see the discussion in phabricator; this comments makes more sense as a whole after reading that, too). I believe most people are experiencing this bug because of task manager - the chain of autohide misbehaving in this case is something like this: * Application wants attention -> * Task Manager notices the application and wants attention -> * Panel not autohiding since a plasmoid (Task Manager in this case) wants attention. However, IMHO the panel should autohide no matter what plasmoid wants attention - just that no other plasmoid seems to cause this, or does it only very rarely, should not be a reason to have this prevention of autohide in the first place. That's just weird design - can't think of any reason / situation I'd want to be notified this way! I also firmly believe the behavior user experiences is not something even the developer of a application wanted. Many applications might not even be aware / had nothing to do with KDE/Plasma when they made their application. I'm speculating here: perhaps the whole feature is poorly documented, and/or even misunderstood by developers? In any case, the current situation is a mess, as there is no way for the end user to disable it, and bad assumptions have been made when designing the whole thing. However, it is difficult to say for sure - in case someone knows of some pointers to documentation, which any programmer making an application should adhere to, would be a nice addition to this discussion. It would still be a mess to fix each and every application! I have problems regularly with Steam client, Firefox, and FAHControl (these are just most annoying and often re-occuring examples - there are others). None of these were probably dessigned this way with the intention to clutter user desktop interface! FWIW, I think I've had a few cases of some system tray icon preventing autohide, which I would not have rather had. They have happened only rarely, and I don't remember the details. I don't believe there are any other plasmoids which could seek attention - and if they did, they would certainly be promptly removed from the task bar. Sadly, the task manager is a major point of having the panel in the first place, and there is no good replacement. In summary: I believe this should be fixed at the panel level (not per-plasmoid, as proposed in Fabricator). However, a task-manager specific option would be welcome, too, to at least alleviate the problem. Also, some pointers to documentation would be welcome - is this really something application makers are and/or should be aware of, when making their applications? >just that no other plasmoid seems to cause this, A quick grep shows no others of ours do set that state. But there's the AcceptingInput state which the previous patch also affected. Given a plasmoid can be assigned a shortcut it unquestionably makes sense for that to raise the panel in that case. It was super important to keep the panel open whilst you're meddling with a dialog. My change to watch transient windows removed a lot of the need for that, but you still have something like Milou in a panel where you're typing. > - in case someone knows of some pointers to documentation, https://standards.freedesktop.org/wm-spec/wm-spec-latest.html _NET_WM_STATE_DEMANDS_ATTENTION it is a very very old spec, before Plasma. Maybe before KDE2. > FWIW, I think I've had a few cases of some system tray icon preventing autohide, >I believe this should be fixed at the panel level (not per-plasmoid, as proposed in Fabricator) I won't block a TaskManager patch. Doing it at a panel level breaks things and doesn't fix anything else. Created attachment 121460 [details]
patch to prevent Task Manager wanting attention if an app's window sets the flag
I found this while digging around for candidate patch spots in task manager.
Still not sure if it's suitable for merging but perhaps it's closer to the right spot?
Instead of commenting out the code, you should add an option in its settings window to control this behavior. May take me a good long while to work out how to do that, any of you other irritated folks want to give it a crack? Check out how configurable options are implemented: https://cgit.kde.org/plasma-desktop.git/tree/applets/taskmanager/package/contents/config Created attachment 121479 [details]
Add the option to prevent Task Manager unhiding panels when a window wants attention
Ooh so I was looking in the wrong spot the whole time? plasma-workspace and plasma-desktop are separate packages on gentoo..
Thanks to your hint, I worked out how to make it optional with a checkbox in task manager configuration :D
Let me know if it's ready for phabricator or if it needs more polishing.
LGTM! Please put it up on Phab and we we can do the code review there. I have updated https://phabricator.kde.org/D12916 with the latest patch and relevant details. Marked as regression as per https://phabricator.kde.org/D12916#500368 in response to https://phabricator.kde.org/D12916#500358 Solution still being discussed, currently considering re-instituting KDE4 behaviour where a simple mouse-over of the panel "acknowledges" 'wants attention', allowing panel to hide without focusing relevant windows. Created attachment 124022 [details]
Add the option to prevent Task Manager unhiding panels when a window wants attention
Patch updated for 5.16.5, also submitted to Phabricator
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/57 (In reply to Bug Janitor Service from comment #26) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/57 There's yet another place to post patches? Didn't know this was an option.. Hexchain's patch doesn't include the settings checkbox that mine has though We switched from phabricator to gitlab in June. *** Bug 416999 has been marked as a duplicate of this bug. *** Created attachment 135941 [details]
Add the option to prevent Task Manager unhiding panels when a window wants attention
Updated patch for 5.20.5.
I guess I should open a merge req on gitlab since apparently phabricator got deprecated since I submitted it there.
Well, I _would_ open a merge req on invent.kde.org except it won't accept my ssh keys - https://invent.kde.org/websites/identity-kde-org/-/issues/3 if anyone's curious Merge request posted at https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/362 Git commit 6779cfc8b11cee069833748600ceeabab1f791d5 by Nate Graham, on behalf of Michael Moon. Committed on 25/02/2021 at 18:40. Pushed by ngraham into branch 'master'. [applets/taskmanager] Add option to avoid popping out hidden panel This option controls whether a hidden panel will become visible when this Task Manager receives a "needs attention" status for one of its apps or tasks. FIXED-IN: 5.22 M +4 -0 applets/taskmanager/package/contents/config/main.xml M +11 -0 applets/taskmanager/package/contents/ui/ConfigBehavior.qml M +1 -1 applets/taskmanager/package/contents/ui/main.qml https://invent.kde.org/plasma/plasma-desktop/commit/6779cfc8b11cee069833748600ceeabab1f791d5 (In reply to triffid.hunter from comment #24) > Marked as regression as per https://phabricator.kde.org/D12916#500368 in > response to https://phabricator.kde.org/D12916#500358 > > Solution still being discussed, currently considering re-instituting KDE4 > behaviour where a simple mouse-over of the panel "acknowledges" 'wants > attention', allowing panel to hide without focusing relevant windows. Is there already a follow-up feature request for "acknowledge on mouse-exit from panel"? FWIW, I will be pushing to re-open if the "solution" requires either moving the mouse, or using a panel (rather than latte), as my reported issue was funneled as a duplicate into this one. I am not aware of a follow-up regarding the mouse-off acknowledge regression, feel free to create one. The resolution to this bug affects the Task Manager plasma widget; I have no idea what "latte" is in this context, or whether it uses the affected Task Manager plasma widget though. (In reply to andydecleyre from comment #35) > FWIW, I will be pushing to re-open if the "solution" requires either moving > the mouse, or using a panel (rather than latte), as my reported issue was > funneled as a duplicate into this one. I just checked what you're talking about here - bug #416999 I presume? Yes, the fix for this bug should be precisely what you're looking for - in fact, the resolving commit touches the same code that your quick kludge removes ;) (In reply to triffid.hunter from comment #36) > I am not aware of a follow-up regarding the mouse-off acknowledge > regression, feel free to create one. Bug 435095 *** Bug 437126 has been marked as a duplicate of this bug. *** *** Bug 406857 has been marked as a duplicate of this bug. *** *** Bug 404687 has been marked as a duplicate of this bug. *** This bug still happens for me in plasma 5.24.7. Autohide works until another window, perhaps on another desktop, wants attention. Then the taskbar pops up. Then I have to click on that window in order to get the taskbar to autohide again. The fix for this issue was to add a setting in the Task Manager configuration page that lets you disable the behavior if you don't like it (some are fine with it, while others don't like it). It's off by default, so you have to turn it on. Confirmed. Found it by right clicking on the panel => "configure task manager", then "behavior", then "When panel is hidden" checkbox. Yep, even though I (finally) got a more sensible behaviour merged, it's always wise to maintain the existing behaviour as default unless someone far more deeply involved in the KDE project than I decides to change the default - so yeah you have to go turn "unhide when a window wants attention" off in the task manager behaviour settings :P |
Created attachment 112573 [details] Patch to prevent panel un-hiding when a window wants attention I love an auto-hiding panel. However, if any window wants attention, the panel will *never* hide until I have given focus to each and every attention-seeking window across all desktops. This infuriates me. The attached patch fixes this behaviour, so the panel will only appear when I mouse over its activation area or it's being configured, but not if windows want attention. I expect there's a more elegant/appropriate way to do it, but I'm not familiar with KDE's codebase so I started here.