Bug 464856 - Non-maximized auto-hidden Panel should un-hide when cursor moves to any part of its screen edge, not just the part of the edge that's over the panel
Summary: Non-maximized auto-hidden Panel should un-hide when cursor moves to any part ...
Status: RESOLVED INTENTIONAL
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (other bugs)
Version First Reported In: 5.26.5
Platform: Other Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: usability
: 484589 509824 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-01-26 16:36 UTC by tim
Modified: 2025-09-23 15:02 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2023-01-26 16:36:46 UTC
SUMMARY
***
The current behavior, while intentional, deviates from the standard used by Latte, DashToDock and MacOS.


***


STEPS TO REPRODUCE
1. Use the "Floating Panel" and "center aligned" options for the main tray, leaving some room on either side.
2. Move cursor to screen edge where "empty" space is
3. Grope around until you find the panel.

OBSERVED RESULT
Panel does not un-hide unless the cursor hits the area where the panel is.

Video:
https://drive.google.com/file/d/1m8AhEK9JtxFNq1RyV9bMym7WKN4R-LFd/view?usp=drivesdk

EXPECTED RESULT
Panels should un-hide when cursor hits anywhere on the screen edge, unless otherwise specified, e.g. in the case of a miniature clock or media player plasmoid on the side. Current behavior doesn't make sense for a main panel, and deviates from the behavior of other popular panels like Latte, DashToDock and MacOS.

SOFTWARE/OS VERSIONS
SOFTWARE/OS VERSIONS
Operating System: Kubuntu 22.10
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.6
Kernel Version: 5.19.0.30
Graphics Platform: X11 and Wayland

ADDITIONAL INFORMATION
Bonus points for a configurable "Intelligent Auto-hide" ability, where the user can select whether to show the panel unless a window takes the space etc.
Comment 1 Nate Graham 2023-01-27 17:37:26 UTC
You said, "Panel does not un-hide", but you didn't mention configuring the panel to be auto-hide. Can you confirm that the panel is set up to be auto-hide, and that whether it's set to "Floating Panel" mode or not is irrelevant to this behavior?
Comment 2 tim 2023-01-27 18:45:25 UTC
(In reply to Nate Graham from comment #1)
> You said, "Panel does not un-hide", but you didn't mention configuring the
> panel to be auto-hide. Can you confirm that the panel is set up to be
> auto-hide, and that whether it's set to "Floating Panel" mode or not is
> irrelevant to this behavior?

Correct, it's set to automatically hide. This report is the cleaned up, wishlist version of another report, as requested.


https://bugs.kde.org/show_bug.cgi?id=464162


Let me know if this is clear.
Comment 3 tim 2023-01-27 18:47:26 UTC
(In reply to tim from comment #2)
> (In reply to Nate Graham from comment #1)
> > You said, "Panel does not un-hide", but you didn't mention configuring the
> > panel to be auto-hide. Can you confirm that the panel is set up to be
> > auto-hide, and that whether it's set to "Floating Panel" mode or not is
> > irrelevant to this behavior?
> 
> Correct, it's set to automatically hide. This report is the cleaned up,
> wishlist version of another report, as requested.
> 
> 
> https://bugs.kde.org/show_bug.cgi?id=464162
> 
> 
> Let me know if this is clear.

Ugh, I really wish there were a way to edit these. Yes, I definitely should have mentioned that. My bad.
Comment 4 Nate Graham 2023-01-27 22:36:40 UTC
Thanks. Re-titling for clarity.
Comment 5 fanzhuyifan 2024-02-17 00:34:44 UTC
I think this makes sense -- currently having both screen edge actions and a auto-hiding panel on the same edge is broken anyways.

One concern is that this might degrade the ability to interact with other UI elements near screen edges, like scroll bars on the right.

Another question is whether we want to support multiple auto-hide panels on the same edge.
Comment 6 Nate Graham 2024-02-17 00:47:02 UTC
(In reply to fanzhuyifan from comment #5)
> One concern is that this might degrade the ability to interact with other UI
> elements near screen edges, like scroll bars on the right.
It's already an issue, so at least that wouldn't be a regression.

> Another question is whether we want to support multiple auto-hide panels on
> the same edge.
That's a good point.

My first thought is that if there's only one auto-hide panel, make its activation zone span the entire screen edge. And if there's more than one, don't, and give each one an activation zone linked to its shape.
Comment 7 fanzhuyifan 2024-02-17 00:49:35 UTC
(In reply to Nate Graham from comment #6)
> (In reply to fanzhuyifan from comment #5)
> > One concern is that this might degrade the ability to interact with other UI
> > elements near screen edges, like scroll bars on the right.
> It's already an issue, so at least that wouldn't be a regression.

I think this would be a regression if such an auto-hide panel has small length. Currently it only interferes with the part of the edge corresponding to its shape, but with this change it will interfere with interactions on the whole edge.
Comment 8 Nate Graham 2024-02-17 00:51:36 UTC
True. I wonder how often people put a single small auto-hide panel on a screen edge though.
Comment 9 fanzhuyifan 2024-03-27 15:59:28 UTC
*** Bug 484589 has been marked as a duplicate of this bug. ***
Comment 10 subhasutra 2024-12-07 12:56:13 UTC
I understand there hasn't been much activity on this, but it would be really nice to have this implemented, as with a smaller panel it is quite easy to miss the trigger area. The entire screen edge trigger would be amazing to have, even as some option instead of default behaviour.
Comment 11 Nate Graham 2024-12-10 21:05:21 UTC
A complication is what happens when someone has multiple auto-hide panels on the same screen edge? It's possible and valid.
Comment 12 subhasutra 2024-12-10 23:40:25 UTC
(In reply to Nate Graham from comment #11)
> A complication is what happens when someone has multiple auto-hide panels on
> the same screen edge? It's possible and valid.

I don't have enough knowledge to comment if these can implemented, but theoretically I can think of two solutions. 
1. There can be a toggle in panel settings to bring up all the panels at once, on that particular screen edge where panel resides, while default is the current behaviour - each panel has its own trigger area.
2. Have a way to set the trigger area in panel settings with respect to panel length, 100% being the default. Increasing it significantly can help reach the state where pushing against just the screen edge will trigger it.
Comment 13 subhasutra 2024-12-10 23:48:40 UTC
> My first thought is that if there's only one auto-hide panel, 
> make its activation zone span the entire screen edge. 
> And if there's more than one, don't, and give each one 
> an activation zone linked to its shape.

This can be a clean solution as well without adding any more options/complexity.
Comment 14 Nate Graham 2024-12-10 23:50:11 UTC
Yeah, that sounds like it could work.
Comment 15 Niccolò Venerandi 2024-12-12 13:08:14 UTC
I discussed this with Vlad from KWIN and I'm currently closing this as intentional, though I am ready to discuss this again if there's *significant* interest from people. This would require changes in the protocol between Plasma and Kwin, it would probably be quite annoying on ultra-wide monitors (it would either have to be an option, which I really don't want, or only happen on certain sizes of monitors/panels, which would be arbitrary), plus other technical reasons ("kwin does not hide the panel after the pointer leaves it; you'd need to rework the entire mechanics behind panel autohiding so plasmashell doesn't need to take care of enter/leave events to avoid the panel getting stuck if you accidentally bump into a screen edge"). Right now, this does not seem to be worth the technical burden to implement and maintain it.
Comment 16 Nate Graham 2025-02-19 21:02:50 UTC
*** Bug 499833 has been marked as a duplicate of this bug. ***
Comment 17 Niccolò Venerandi 2025-09-23 15:02:20 UTC
*** Bug 509824 has been marked as a duplicate of this bug. ***