| Summary: | Edge barrier behaves unpredictably, causing irritation in use | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | qlum <qlumreg> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | cwo.kde, fanzhuyifan, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Diagonal movement | ||
|
Description
qlum
2024-06-24 19:59:47 UTC
Have you tried setting the edge barrier to a smaller value? Currently it is intentional that the barrier is harder to cross with slower movements -- this prevents unintentional crossings. On the other hand, there is absolutely no dependence on angle of movement -- the crossing only depends on the speed orthogonal to the edge (e.g., horizontal space for vertical edges). If it just counts movement orthogonal to the edge, wouldn't this make the barrier seem larger for diagonal movement? For example, if you move at an exact 45° angle from left to right, by the time you've moved right 100px, you also moved 100 pixel vertically, so by the Pythagorean theorem the distance you need to travel before breaching the barrier is ~141 px, almost 50% extra. Created attachment 170947 [details]
Diagonal movement
Okay, so it is intentional behavior, for me personally that means I will not use this feature, but that's alright.
My intended use-case was to roughly map the edge barrier to roughly the physical distance between screen edges.
However a speed depended barrier does not fit my use-case, regardless of how strong it is.
I will however add that a value in px is rather missleading as it can be anything between almost nothing at high speeds to infinite if your mouse speed is slow enough.
As for diagonal movement, I think the problem is that because you are moving diagonally the horizontal movement speed is also lower, making it harder to cross the barrier.
Small adition to my previous comment, I was using a Edge barrier of 10px when showcasing the diagonal movement. All of this is intentional, yeah; it's designed to make slow movements easier to constrain to one screen so you can reach UI elements touching a screen edge more quickly. If you don't like it, you're welcome to turn it off. (In reply to Nate Graham from comment #5) > All of this is intentional, yeah; it's designed to make slow movements > easier to constrain to one screen so you can reach UI elements touching a > screen edge more quickly. > > If you don't like it, you're welcome to turn it off. Fair, not trying to get it my way, just airing how I see it personally. This will be what I have to say about this: The way it's phrased now with just a value in px is misleading, it gives the impression that we are talking about a fixed distance. As for diagonals, I don't know how easy it would be to implement. But those are a lot harder to cross as at a given speed their horizontal speed is lower, so taking the combined horizontal and vertical speed into account when moving through the barrier would already make things feel more consistent. (at least to me). Exposing something like a speed multiplier as an extra control would give users (including me) more control on how the zones work and what feels right to them. Ah, if it's just about diagonals, that may be a legit issue if you've got your screens configured so that they really are diagonal to each other. Can you attach a screenshot that shows your screen layout on System Settings Display & Monitors page? And if it really is about moving diagonally between screens, it's Bug 483651, which has a fix in progress. (In reply to Nate Graham from comment #7) > Ah, if it's just about diagonals, that may be a legit issue if you've got > your screens configured so that they really are diagonal to each other. Can > you attach a screenshot that shows your screen layout on System Settings > Display & Monitors page? Not at all just a factor in making it feel inconsistent for it's intended use. Just to sum up my personal core issue: My intended usecase for this feature is to use the edge barrier as some sort of virtual space between my screens. The current speed dependent implementation is not useful for this use-case. The reason I want this is to offer mouse movements that map more directly to what I see. If I move my mouse 1cm that corrsponds to a 15cm movement of my cursor in my current setup, however if I cross a 3cm space between screens that 15cm will visually overshoot. If there was a screen barrier that was a fixed number in px, independent of movement speed, I could set it to roughly 280px and create movements that better map to the real world movement of the cursor, while at the same time offering a buffer zone for window snapping. A setting to change / disable the velocity component would make this a useful feature for me, as it stands now it's detremental. So I guess it's a minor feature request. That's an interesting use case, but it's not really what the edge barrier feature was implemented to accomplish. Monitors physically displaced from one another are not formally supported in the sense of generating extra dead space between them. We allowed this in the past and it unleashed a torrent of weird bugs. |