D12916: Panel should not stop auto-hiding if a window wants attention
Eike Hein
noreply at phabricator.kde.org
Mon Jul 22 19:06:14 BST 2019
hein added a comment.
In D12916#500367 <https://phabricator.kde.org/D12916#500367>, @davidedmundson wrote:
> "does the task manager need attention simply because some different window needs attention"?
There's an easy answer: We have a lot of users who rely on that.
A lot of people want to be able to focus without disturbance, but a lot of people also don't want to miss that important notification they're waiting for. For the latter, having an off-desktop window be able to punch through and raise the panel is important.
If you look at industry trends, there's currently a very active discussion on how to mediate the range of "leave me alone, all these notifications are killing me" and "let the important stuff punch through". In 5.16 we introduced some of the same ideas others have: DND mode and per-app configurability.
This problem is broadly part of the same conversation and so it's not really specific to the TM or the panel. What the TM does is provide a view into system state sharded by application. The notification applet does the same. The window attention state and notification messages are both notification mechanisms. Some of the "can this punch through?" configurability should likey be there, because most definitely some things should be able to.
The other angle to attack this problem from is purely the panel UX, where you can pick between the model of "attention is needed permanently until nothing needs attention" and a model of "requests for attention need to be explicitly acknowledged, and after they have been can be ignored", i.e. allowing the panel to hide after enter+exit clears a bit. I like this one.
REPOSITORY
R119 Plasma Desktop
REVISION DETAIL
https://phabricator.kde.org/D12916
To: michaelmoon, ngraham, hein
Cc: hein, ngraham, davidedmundson, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190722/b487b2e4/attachment-0001.html>
More information about the Plasma-devel
mailing list