Overview: 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 resistance. 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: https://bugzilla.xfce.org/show_bug.cgi?id=11456 https://git.xfce.org/xfce/xfwm4/commit/?id=df707c36a4d0d2903593855dd3575ff4a6aade23 Thank you!
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.
(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
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!
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 @@ #endif #ifndef MAX_SNAP_DRIFT -#define MAX_SNAP_DRIFT 15 +#define MAX_SNAP_DRIFT 150 #endif #define XFWM_FLAG_HAS_BORDER (1L<<0)
-- 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