Bug 312958 - Desktop Effects - Zoom: Keep "Push" add an optional "dynamic mouse push", which pushes as long as the mouse is on the screen border
Summary: Desktop Effects - Zoom: Keep "Push" add an optional "dynamic mouse push", whi...
Status: RESOLVED DUPLICATE of bug 312956
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: 4.9.5
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-09 16:27 UTC by tormen
Modified: 2013-01-09 17:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tormen 2013-01-09 16:27:06 UTC
The currently implemented "push" fnctionality: The moving in [larger] distinct steps of x pixels or x percent (?) at a time is a good solution for keyboard controlled movements of the zoom area!
Even though a parameter to determine x would be nice to have.

But for mouse driven pushes of the zoom area the compiz/fusion approach of having a dynamic/instant push executed as long as the mouse pointer is [moved onto] the screen border (so the push stops as soon as you move the mouse pointer away from the screen border) is a more rapid, more precise and more flexible approach IMHO.


Reproducible: Always
Comment 1 Thomas Lübking 2013-01-09 16:46:19 UTC
pretty much bug #312956 / aspect (b) - at least would very likely be part of the duplicates resolution (because from a wild guess the current behavior has some timered trigger, what explains the random behavior.

*** This bug has been marked as a duplicate of bug 312956 ***
Comment 2 tormen 2013-01-09 16:52:25 UTC
Hmmm... I don't want to be annoying :)

... but again I don't agree: Because I am suggesting really something *new* here:
At the moment there is only a zoom that zooms in *fixed length* steps (probably a portion of the screen, so % - which I mentioned should be choosable) but I am suggesting instead (which for a /mouse/ purpose makes sense: a mechanism that allows to push with a *dynamic length* as it will push as long as you keep the mouse at the screen border.
Comment 3 tormen 2013-01-09 16:56:19 UTC
I al(In reply to comment #1)
> because from a wild guess the current behavior
> has some timered trigger, what explains the random behavior.

I had the same idea :) .... I also just tested the keyboard shortcut use of the push function which nicely seems to work flawless, reactive and as expected :)

... but for mouse push there should still be another mode (like suggested here) IMHO
Comment 4 Thomas Lübking 2013-01-09 17:15:42 UTC
keyboard and mouse "push" have not much in common anyway and the mousepush implementation as present is simply not working and unusable.

Yes, the idea is you can touch the border and immeditely bove back the mouse,  resp. keep it in the same position, but given a reasonable animation time, that coordination cannot be done before the animation stops anyway and as you figured the outcome is pretty unpredictable (because of the not pre-known move distance as well a the random behavior).
Comment 5 tormen 2013-01-09 17:26:52 UTC
When you switch the "Mouse Tracking" to "Centered" then you can still move with the shortcuts (even multiple, consecutive times), but everytime you release the shortcut keys (the screen jumps back to the centered mouse pointer) .... understandable but unintuitive and certainly unintended behaviour, because if I press the keys to move the zoom pan, then this should "overwrite" the Mouse tracking.

Otherwise: The "centered" mouse tracking mode shows nicely the sort of dynamic mouse driven zoom-area-move as I envision it for the Mouse Tracking "push" (but of course the difference is that in push mode the move of the zoom area only happens when the mouse pointer is at the screen border).
Comment 6 tormen 2013-01-09 17:28:16 UTC
Also a zoom factor below 1 is kind of useless .. as this just inverses the zoom in and out ;)