| Summary: | Make it possible to have the pointer over the auto-hide panel's trigger | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Fernando M. Muniz <fernandommuniz> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | kdedev, nate |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | 6.4.4 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=502084 https://bugs.kde.org/show_bug.cgi?id=510723 https://bugs.kde.org/show_bug.cgi?id=510746 |
||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
I asked Nate about how exactly this trigger behaved and he didn't know. So I created this wishlist under the hopes that it could be made hoverable.
Comparing the reach of the cursor. |
||
|
Description
Fernando M. Muniz
2025-08-21 06:12:05 UTC
Created attachment 184307 [details]
I asked Nate about how exactly this trigger behaved and he didn't know. So I created this wishlist under the hopes that it could be made hoverable.
Thanks for creating the feature request. I'm passing this along to the developers. Can you clarify what problem would this solve? What pain is the current implementing causing you? In general, it's always a requirement to know what the problem is with the status quo when requesting a change to it. (In reply to Nate Graham from comment #3) > Can you clarify what problem would this solve? What pain is the current > implementing causing you? In general, it's always a requirement to know what > the problem is with the status quo when requesting a change to it. Windows getting stuck under that line isn't a small bug? What do you mean by "windows getting stuck under that line" How does one trigger this? As shown in the attachment, if a user decides to hide a window by moving them to a corner, then later changing the panel to that corner, the window becomes inaccessible. If the user doesn't know it's the panel causing it, then they will have to close the app, losing unsaved work. If the user doesn't know about the line, it's also hard to tell if the screen is being overscanned. The issue can become even harder to track when using multiple panels. And this might affect session restore too, if it remembers the window position. > if a user decides to hide a window by moving them to a corner
Then don't do that? How did you even manage to do this anyway? I can't seem to do it. Dragging a window to an edge or a corner triggers quick tiling, and if I try really really hard to avoid it, I still can't drag the window 99.99% offscreen such that only a single pixel is visible; it always preserves a bit of the window I can grab.
How are you managing to end up in this state?
Seems like the windows are getting re-positioned when the panel is moved there now, so that issue can't happen anymore. I guess I'll have to learn C++ if I want the trigger areas to be hoverable, quite annoying that the screen is never pixel-perfect because of it. What do you mean never pixel-perfect? Being able to hover to every pixel shown would be a pixel-perfect in regards to the pointer. But why? For what purpose? (In reply to Nate Graham from comment #11) > But why? For what purpose? Because it's something I can't unsee due to my adhd. Is there a way of paying someone to do this? But what is it that you see? It's still not clear to me. We already establishes that you can't actually drag a window off the edge such that only one line of pixels is visible. What is the problem here? As of now, it's just the the inaccessible line itself. I guess I'd be willing to pay a dev to do it (especially if they are Brazilian, for economic reasons). It's probably possible to pay someone to fix the issue. But I'm still not understanding what you mean about an inaccessible line of pixels; I don't understand what the issue actually is, because I can't reproduce any issue. Visually everything looks fine to me on the screen edge with an auto-hiding panel. I can jam my cursor into that edge and it will move exactly as far as it will when there's no panel on that edge, or an always-visible panel. Created attachment 184566 [details]
Comparing the reach of the cursor.
The issue is that you can't access that line pixels and have the dodge-windows/auto-hide panel in there at the same time, because that line of pixel is something to be pushed against, instead of it being a "intangible tracker of the pointer speed towards the panel's corner".
If it was the latter, it would allow the area to be clickable, while not changing the behavior of the panel.
The easiest way to notice is by having an auto-hide panel on the left corner, then slowly flicking the touchpad towards the trigger. You'll notice that you can see the left contour of the cursor, which is not the area you click, but while the panel is showing you can't see the left contour; meaning that the pointer is reaching the last pixel of the screen.
Now that I think about, this line (see attachment) should be very noticeable in low resolutions. Besides the panel and the screen edges feature, does anything else use this type of trigger? Does low resolution works as a valid situation where this can be seen as a bug worth fixing? If not, I think I'll just start a discussion about it on the forum. There has to be someone that doesn't like losing 6.000 pixels and would like to see them clickable. Yeah, I don't think there's an actual issue here, sorry. In theory, all it needs to be done is to replace the panel's "physical trigger" code with Haruna's "non-physical trigger" code from its brand new Playlist Sidebar, while keeping all the other aspects the exact same (1 pixel wide trigger, pointer speed required towards the panel). |