https://bugs.kde.org/show_bug.cgi?id=496045
Bug ID: 496045
Summary: [wishlist] Zoom mouse tracking further option
Classification: Plasma
Product: kwin
Version: git master
Platform: Other
OS: Other
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: effects-various
Assignee: kwin-bugs-n...@kde.org
Reporter: 1i5t5.dun...@cox.net
Target Milestone: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
