Bug 496045

None of the current zoom mouse trackers does what I actually want/need.  Xorg allowed configuring a panning area smaller than the desktop in its native config files, effectively the margins I'm asking for below (tho my memory of the details and how they corresponded to kwin-zoom's centered/proportional/push choices is fading), but kwin wayland doesn't seem to have anything similar.

My layout: Multi-monitor, three 4k monitors in "L" layout (to be four in a 2x2 grid whenever I finally upgrade and can plug in the fourth one).

The behavioral issue with centered and proportional is basically the same, in different spots.  The issue with push is quite different.

* Centered:  The problem here is that on a multi-monitor setup "center" is often *exactly* at the split between monitors, making it difficult to see what's actually at the click-point because it's spread over multiple monitors and possibly partially off-screen (L layout with a quarter of the centered widget on the missing monitor). 

If it were "approximately centered", basically "push" but with a small centered confinement area of say 5-33% (configurable in 1% steps), instead of the current exact-center pixel or pixel edge/corner, that would allow one to "overshoot-push" to slightly off-center the target widget to one or another monitor, then back off some to actually click it without forcing it to the very center across multiple monitors.

The current situation is particularly frustrating when I'm trying to double-click a corner titlebar button (say the windows actions button to close), and in not /quite/ seeing what I'm clicking, end up double-clicking the titlebar itself instead (thus end up say maximizing the window I'm trying to close!).

If I could overshoot and back off so the target button could remain displayed on one monitor even as I centered the pointer over it, I could see and actually click it properly!

Another frustrating problem with "centered" appears with focus follows mouse and for instance a konsole window against the center edge of a monitor, with another window next to it on the center edge of the opposite monitor.  To see and read the contents of the window on one monitor instead of split between monitors while repeatedly swinging the mouse to the other window to focus it, and back to focus the first again, is more difficult than it should be.  If my mouse swing is slightly too far one way the konsole window is focused fine but its contents is split across monitors and difficult to read.  If the mouse swing is slightly too far the other way the window positioned next to it but on the other monitor ends up under the mouse and focused, and I can read the konsole window just fine on a single monitor but can't type into it without refocusing.  (The problem is worst when I've multiple konsole windows open, say one with a list of kde packages with git updates, and another I'm reading the git logs in.  Repeatedly read a few logs, swing the mouse to perhaps scroll the list some and move my package-placeholder selection in the list window, swing it back to read a few more logs... if I don't get it exactly correct with the swing to the log-reading window, either it doesn't get focused and anything I type goes into the list window instead (losing my place, oops!), or the log-reading window gets focused but now the content is across multiple monitors and hard to read.  Back and forth.  Get the swing just right.  Wash.  Rinse.  Repeat.)

Again, if the "center" were a push area some percentage across instead of the exact-center pixel or pixel edge/corner, I could more easily switch between the windows with focus under mouse, without actually disturbing the display of my reading area.

Proportional:  The problem here is sort of  similar to that of centered; it's difficult actually seeing what I'm pointing at, only here it's at the desktop edge instead of the desktop center.  In ordered to see something at the desktop edge, I have to move the mouse *all* the way to the edge and keep it there.

In the worst case that triggers an autohide panel that covers what I'm actually trying to point at, obscuring what I'm trying to read or click.  Even when the window I'm working in stays focused, if I'm trying to click a widget I may have to back off from the edge a bit, thereby potentially hiding part of the widget I'm trying to click.

The fix would be configuring a margin at say 5-33% (1% steps) from the display edge that becomes the calculated edge for the purposes of proportional mouse tracking, so the display pans to the edge before the mouse actually gets to it.  That way buttons and other content at the edge can be properly viewed and clicked, and edge-triggered panels don't get triggered (or if they are one can back off and go a bit slower, without having to do the "carefully creep up on it but don't actually trigger it" maneuver currently required).

Push:  The problem with push is quite different.    Here, the issue is simply the sheer size of what amounts to (in my case) an 8k display bounding area, and the fact that it can be a loooong way between edges.  If I accidentally overshoot my intended target, I have to shoot aaalllll the way to the other side, either going fast, taking advantage of mouse acceleration to get there quickly, but at a very high risk of overshoot now in the /other/ direction (wash, rinse, repeat...), or going slow to avoid the overshoot risk but taking forever to actually get to the other side to accomplish the likely just a few px nudge that's needed.   That effectively rules out push as currently implemented as workable at all on a large enough desktop.

Conceptually a fix here would be similar to that of proportional, a configurable percentage margin before the actual edge at which the push occurs.  Once the display edge is reached push-panning would of course stop and the mouse would move the rest of the way within a fixed display.  With a large margin of say 33% the push edges would be that of the center third, substantially reducing the necessary travel distance, especially in the case of overshoot correction.

As mentioned at the top, at least one of these (push with margins? proportional with margins? both? IDR the exact details) was configurable on xorg as it allowed configuring panning area separate from full desktop area, thus effectively allowing configurable margins.  Unfortunately I'm not aware of anything similar for kwin/plasma wayland.

So the request is for at least one of these.  Ideally the same margin configuration and calculation code can be reused for all three, making it very little more code to implement it for all as opposed to just one, but I'm just asking for one.