The wrap workspaces function seems to require diagonal motion at the screen edge to trigger a wrap. Often times my pointed motion is perfectly or almost perfectly perpendicular to the screen edge, so wrapping does not behave consistently. The edge resistance is inconsistent, depending on whether the pointer motion was perfectly perpendicular to the screen edge or slightly diagonal. Often I have to "slap" the pointer around on the edge of the display to trigger a wrap. Upon further investigation, I found that the edge resistance paramenter seems to define how much non-perpendicular motion is required to trigger a wrap. This is based on empirical trials. I have not yet investigated the code. I believe that both perpendicular and non-perpendicular motion at the screen edge should be cumulated against the resistance value. Reproducible: Always Steps to Reproduce: 1. Move the pointer perfectly perpendicularly towards a screen edge 2. Wrap will not occur. 3. Allow even 1 pixel of non-perpendicular motion, then wrap will trigger. Actual Results: As described, workspace wrapping does not occur with pointer motion perpendicular to the screen edge. If I deliberately drag the pointer diagonally across workspace edges (at 45 degrees, say), then workspace wrapping and edge resistance feel and behave correctly and consistently. Expected Results: Pointer motion perpendicular to the screen edge should allow workspace wrapping. I would classify the severity as somewhere between Normal and Major. It's not a crasher, but it is seriously affecting my working experience with Xfce. With just a few tweaks, XFce w/ Xfwm4 could finally displace my 8 year old version of Afterstep 1.0!
The mouse pointer is limited within the screen, so edge resistance depends on movement on the other direction after the pointer has reached an edge. There is no other way to do it, this is noit a bug, or at least this can't be fixed. Sorry.
I humbly disagree. I see two methods of making it work: 1) (ala afterstep) edge wrapping is not based on pointer motion events, but on time spent in the 1-pixel workspace border: Enter_border_window() { Initialize Counter LOOP UNTIL Counter >= Resistance Sleep briefly Increment Counter Check for LeaveNotify event (XCheckWindowEvent) IF event found RETURN ENDIF ENDLOOP Perform workspaceMove() } 2) My briefly thought out idea: Enter_border_window() { IF current time > Last_Timestamp + 100ms Counter := 0 ELSE Increment Counter IF Counter >= Resistance Perform workspaceMove() RETURN ENDIF ENDIF Last_Timestamp := current time XWarpPointer to 1 pixel away from screen edge } Both of these methods would preserve the edge flipping function while removing the aggravating dependancy on non-perpendicular motion events within the border. I think the 2nd method stands a better chance of being easily integrated into XFwm's current code without a lof of work. (And the 100ms value would need some trial and error to find a good number.) If the concept behind either of these methods seems reasonable, possibly with more discussion, I will be glad to prepare a patch for Xfwm.
The problem with both methods is that it's time based while the concept of wrap resistance is really resistance, ie the use has to "force" by moving the pointer. So, I still don't see the need for changing that, it's really the way it's meant.
Did you look at my pseudo-code? Yes, the first method is time-based (and works very well in Afterstep, IMHO), but the second is _not_ time based, and _does_ require the user to 'force' the edge flip by providing continuous motion of the pointer until a resistance threshhold is reached, but is not dependant on non-perpendicular motion. The timestamp is only there to make sure that the resistance is reset once the pointer stops moving against the screen edge and that occasional bumps into the screen edge don't keep cumulating the resistance counter. Look again, and I think you'll agree. I'm confident that it will work well, so I will go ahead and implement it as my time permits and offer you the chance to test drive it.
I think you might underestimate the current implementation. But if you really think you can do better, go ahead, write a patch and we'll see. I don't promise anything about its inclusion, though.
Created attachment 304 Improved edge resistance mechanism This is my first pass at a functional edge resistance mechanism that does not suffer from a requirement for mandatory non-perpendicular motion against the screen edge. I find it to be much smoother and more intuitive than the mechanism in xfwm 4.2.2. Caveat: If the pointer is moved very quickly, it may appear for the first time inside the 'sidewalk' already against the screen edge, in which case the same 'stuck' condition occurs as before, but this happens much less frequently than with the old mechanism. Questions: 1) Is there any downside to a larger sidewalk (say, 10+ pixels), other than a few extra calls to handleMotionNotify (that will quickly bail out after a bounds check)? 2) Is there a way to force a pointer motion event when the pointer first enters the sidewalk? Either of these would eliminate the above caveat and provide a perfect solution.
> 1) Is there any downside to a larger sidewalk (say, 10+ pixels), Yes, events aren't received by client windows. > 2) Is there a way to force a pointer motion event when the pointer first enters the sidewalk? Humm, nope, you get a enter event then.
I'm sorry, I tried your patch and did not notice any improvement. What I fail to understand is how this can be improved, because by definition, once the pointer has reached the edge, the pointer is blocked and doesn't move anymore. Therefore, the only way to generate and receive the motion events is to move the pointer in the perpendicular direction (for ex. up and down when reaching the left or right border). Your patch makes no difference for that...
Created attachment 305 Improved edge resistance, take 2 This patch completely resolves the issue with missing pointer motion events by additionalyl hooking into the handleEnterNotify function. Edge resistance now works very smoothly, and is completely flawless. I cannot get the pointer to stick on a screen edge anymore. Try it and I'm sure you'll like it. At the very least you should see that it does not inhibit the old functionality in any way, and greatly improves the feel of xfwm4 for me. Let me know what you think, and I'll produce a cleaned up version of the patch (lots of debugging in there right now) ready for merging.
Created attachment 306 Improved edge resistance, take 2, cleaned up for merge Same as previous patch, but eliminates the debugging cruft, ready for merging if approved.
Sorry, but I still fail to see how this patch is an improvement: It just ignores edge resistance (the edge_scroll_x is now ignored and not compared to the actual wrap_resistance setting). The thing is that X doesn't emit motion notify events once the pointer has reached a screen edge. So, to get the motion events, the user has to move the mouse in a perpendicular direction. That's how X works, it's not dependant on xfwm4, nor afterstep, nor whatever, it's X11. The edge resistance setting in xfwm4 is there to allow the user to define how much moves need to be reached before actually perform the worskspace switch. So far for me, your patch is not correct and breaks something that works. Did you try to change the edge resistance setting instead of removing it with a patch ?
Holy cow man, I don't want to get in a big argument over this, but.. are you on drugs? My patch does NOT disable nor ignore edge resistance at all. Both edge_scroll_x and edge_scroll_y are still each compared against wrap_resistance when the applicable edge is encountered. I have tested it with a wide variety of wrap_resistance values, and it DOES what it is intuitively supposed to. i.e. low-resitance = easy to wrap, high-resistance = harder to wrap. The ONLY functional difference between this and the original xfwm 4.2.2 method is that now pointer motion events perpendicular to the screen edge are ALSO counted against the wrap_resistance rather than only non-perpendicular motion. I understand that X does not generate further motion events in the direction of the screen edge once there. I really do understand that. Please look at the patch and see that I have implemented a workaround for that limitation! Do you need a better explanation of how the patch works than what I have already provided several times? Do you need flow-charts and diagrams? I can do that if necessary. If there is anyone else out there in Xfce-land that could test it, that would be great. I am very keen on switching to Xfce/Xfwm for my daily work environment, but do not want to have to start maintaining my own patched versions. I've been doing that for the last 8 years with Afterstep 1.0 because it was the only wm that did absolutely everything I wanted, and was configurable up the wazoo. I'm tired of maintaining it's archaic code, and Xfce/Xfwm seems well positioned to take over, but not if it's going to be such a monumental battle to have a patch merged that clearly improves it's function by eliminating a technical limitation. Please apply the patch. Let the developers and pre-release testers decide for themselves whether it is an improvement. I am very confident that they will agree that it is.
What I was missing is the very simple explanation that your patch just moves the pointer back for 1 pix to allow the mouse to move again. That's the explanation I was expecting (not the "read the code", not "'holy cow", not even if I'm on drug, but simply *why* your patch is an improvement). Just to make it perfectly clear, the switch from afterstep to xfce is not an argument. I don't owe you anything because you might switch to xfce, I really don't care.
OK. My comment #2 with pseudocode described the process of using XWarpPointer specifically to move the pointer back by 1 pixel. I thought that was clear. If you missed that part from the start, then I can understand how you were very confused from that point onward. Still, the patch ought to have spoken for itself. Sorry I got upset. You were saying things about my patch that were clearly incorrect (such as "it just ignores edge resistance") as though you had not read it, so I lost my cool for a bit. I hope that the patch's function is clearer to you now. If you need any further explanation, I would be happy to answer any questions. Does it seem a more likely merge candidate now? BTW: Some advice, one developer to another: the "I really don't care" position isn't the best way to entice future contributors to Xfce. Getting more people onboard using and developing the software is the best way to improve it. Giving people a reason to switch is actually good marketing (just look at Apple!). Thumbing your nose at someone who actively _wants_ to switch and is ready to provide feedback, bug reports, and most importantly _patches_... well that's just plain silly.
I'm working on your patch now, using the same for workspace switch on window moves. The patch should find its way to SVN trunk, as I see this as more of an enhancement, not really a bug fix. The 2-pixel sidewalks is a serious problem because it breaks panel autohide even further. I don't see how to use a 1 pix sidewalk as we would receive a leave notify event that resets the counters to 0...
Ah crap. I never even noticed that edge resistance is handled differently while moving a window. I guess I don't actually do that as much I might have thought. Of course panel auto-hide is an issue. Sorry I didn't consider that since I tend to dislike auto-hiding things. Actually I had thought that the sidewalk could be reduced back to 1 pixel. There is no need to reset the edge_scoll_[xy] counters when leaving the sidewalk, because the timing threshold will take care of that automatically when re-entering the sidewalk if it's been too long (> .5s currently). (I almost removed that code from handleLeaveNotify before, but it wasn't hurting anything so left it.) Since I already have the hooks in handleEnterNotify, it should be easy enough to use that as the primary edge resitance mechanism, moving a bunch of the code from handleMotionNotify into handleEnterNotify, as long as the continued use of XWarpPointer isn't a problem.
The panel autohide is mostly fixed now. However, reducing the sidewalks back to 1 pixel would still be a good thing. If you plan to prepare such a patch, please make sure it's against SVN trunk since it's where things are happening now. If you don't have/don't want/ cannot install subversion, I can provide a snapshot.
Ok, the code has been made a bit simpler and the sidewalks are back to 1 pixel width. I think we can close the bug now as your patch is in SVN. Snapshot available here: http://www.xfce.org/~olivier/preview/xfwm4-4.3.0-r17627.tar.bz2 Thanks for your contribution.