! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Fast mouse movement prevents switching of workspaces.


Description Peter Keller 2017-01-17 04:05:17 CET

When using a pointer device like a trackball, the mouse can move much
faster than with a normal mouse for much longer a distance. Moving the pointer
too fast results in it clipping to the edge of the screen and stopping instead
of changing to the next workspace.

Steps to Reproduce:

Make several workspaces in a single row. Ensure you can switch between them
in a torus like manner.

In the "Window Manager: Configure window behavior and shortcuts" window,
in the Advanced" tab, in the "Wrap workspaces when reaching the screen edge"
section, check "with the mouse pointer" and check "with a dragged window".
Then, "edge resistance" is moved as far left to "small" as possible.

Actual Results:

When I move the trackball to very quickly move the mouse pointer to another
workspace, the mouse pointer slams against the edge of the screen in such a
manner as a physics collide with a wall (meaning, horizontal motion is stopped,
but there could be vertical motion up or down). When the trackball stops, the
mouse is still sitting at the exact edge of the screen, but no workspace switch
has happened.

When the pointer is moved _slowly_ across the screen boundary, a workspace
switch happens. However, even in that case, it still appears there is an edge

Expected results:

There should be absolutely no edge resistance, and the pointer should travel,
with the inertia of the trackball, as far as it needs to go. This would include
completely traveling over entire workspaces until the pointer stops due to the
natural nature of the trackball.

A trackball can move the pointer longer distances much faster than a typical
use of a mouse. There seems to be a "speed limit" when crossing over the edge
of the screen that simply prevents the switching.

The inertia of the trackball is great enough that I expect to move multiple workspaces using this method it extremely quickly (like sub-second, easily)
with a tiny movement of my thumb. It used to do this in xfce 4.10.0 and
workspaces were amazing to so easily go between them.

But, this UI issue is a _major headache_, it affects me *every time* I want to
switch a workspace.

Build Date & Hardware:

Build: xfce 4.12.2 gotten from the XUbuntu 16.04 LTS release.
Hardware: x86_64 machine

Additional Information:

These might be related:



Thank you!
Comment 1 Olivier Fourdan editbugs 2017-01-17 09:01:20 CET
Yes, I was thinking of commit df707c3 as it's pretty much the only change in events.c related to wrapping that could affect this behavior.

You may want to revert it in your own build and see if it helps.
Comment 2 Olivier Fourdan editbugs 2017-01-17 09:06:42 CET
(In reply to Olivier Fourdan from comment #1)
> Yes, I was thinking of commit df707c3 as it's pretty much the only change in
> events.c related to wrapping that could affect this behavior.
> You may want to revert it in your own build and see if it helps.

Or, for a start, build with a much larger value for MAX_SNAP_DRIFT
Comment 3 Peter Keller 2017-01-17 19:35:51 CET
I'll give it a try and see if I can make the behavior better. If I do this
would a patch be accepted (even if it is just a revert of that commit)?
I take it, though, it won't end up in XUbuntu 16.04 LTS as some back patch
so I'll have to continue using my own build?

In addition, might I suggest a change to the interface in the Window Manager
concerning wrapping and edge resistance where a check box like this is added:

[ ] Prevent Unintentional Workspace Switching

When unchecked, workspace switching is unlimited in any way and regular edge
resistance is used (and edge resistance can indeed go down to exactly 0).

When checked, the current behavior (xfce 4.12.2) is performed.

The default value of the box can be whatever you (xfce developers)
choose to be appropriate.

The prevention of unintentional workspace switching is a heuristic
and one single instance of it isn't going to be right for everyone.
So, if people feel strongly about having such a thing, maybe when
the above is checked, then it will "unhide" a set of GUI controls
such as the below (e.g.):

X Velocity Threshold: Zero [ ---[xxx]-------------] High
Y Velocity Threshold: Zero [ -------[xxx]---------] High
Max Snap Drift: [   5   ]

In the future, I humbly predict people will fight over the heuristic
as it is currently implemented.  Instead of having a git fight where
the same piece of code's heuristic continues to be altered to the
satisfaction of no one, if additional people complain about this
heuristic, then maybe "Prevent Unintentional Workspace Switching"
can become a drop down of individual heuristics and then the unhidden
GUI provides parameter control for that particular heuristic.

Thank you!
Comment 4 Peter Keller 2017-01-17 20:22:25 CET
Ok, I set MAX_SNAP_DRIFT to 150 and it solved the problem.

I looked idly at that value and it seems defined in pixels or
something, so if you have regular or 4K screens you're moving between
with the same build (especially a laptop with a 4K screen and a
regular monitor), that seems it might go awry.

I suggest a percentage of screen size for MAX_SNAP_DRIFT instead of
an absolute pixel quantity.

So, at this point, I have a "fix" working for my regular desktop,
but I will probably have to replicate it on several other machines
upon which I'd like to install XUbuntu. :( Ah well.

I deeply thank you for helping get at least some kind of workaround,
it was very difficult to use xfwm4 as shipped in XUbuntu 16.04 TLS with
a trackball.

Here is the patch, if it is any consequence:

diff --git a/src/client.h b/src/client.h
index 7aa93f3..b1b0d27 100644
--- a/src/client.h
+++ b/src/client.h
@@ -117,7 +117,7 @@
-#define MAX_SNAP_DRIFT                  15
+#define MAX_SNAP_DRIFT                  150
 #define XFWM_FLAG_HAS_BORDER            (1L<<0)
Comment 5 Git Bot editbugs 2020-05-29 12:14:15 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/243.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #13292

Reported by:
Peter Keller
Reported on: 2017-01-17
Last modified on: 2020-05-29


Olivier Fourdan
CC List:
0 users




Additional information