! 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 !
Wrap workspaces edge resistance inconsistencies (requires diagonal movement?)


Description Ian Morgan 2005-09-08 22:49:45 CEST
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!
Comment 1 Olivier Fourdan editbugs 2005-09-09 10:28:44 CEST
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.
Comment 2 Ian Morgan 2005-09-09 22:30:33 CEST
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

  Perform workspaceMove()

2) My briefly thought out idea:

Enter_border_window() {
  IF current time > Last_Timestamp + 100ms
    Counter := 0
    Increment Counter
    IF Counter >= Resistance
      Perform workspaceMove()
  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.
Comment 3 Olivier Fourdan editbugs 2005-09-11 15:37:23 CEST
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.
Comment 4 Ian Morgan 2005-09-11 17:33:22 CEST
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

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.
Comment 5 Olivier Fourdan editbugs 2005-09-11 19:06:34 CEST
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.
Comment 6 Ian Morgan 2005-09-12 01:02:40 CEST
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.
Comment 7 Olivier Fourdan editbugs 2005-09-12 10:30:26 CEST
> 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.
Comment 8 Olivier Fourdan editbugs 2005-09-12 10:39:44 CEST
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

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...

Comment 9 Ian Morgan 2005-09-12 16:13:55 CEST
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.
Comment 10 Ian Morgan 2005-09-12 20:00:37 CEST
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.
Comment 11 Olivier Fourdan editbugs 2005-09-13 10:34:31 CEST
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 ?
Comment 12 Ian Morgan 2005-09-13 14:24:56 CEST
Holy cow man, I don't want to get in a big argument over this, but.. are you on

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

If there is anyone else out there in Xfce-land that could test it, that would be

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.
Comment 13 Olivier Fourdan editbugs 2005-09-13 18:45:09 CEST
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.
Comment 14 Ian Morgan 2005-09-13 19:13:50 CEST

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.
Comment 15 Olivier Fourdan editbugs 2005-09-13 19:30:13 CEST
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...
Comment 16 Ian Morgan 2005-09-13 19:58:11 CEST
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.
Comment 17 Olivier Fourdan editbugs 2005-09-13 20:15:30 CEST
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.
Comment 18 Olivier Fourdan editbugs 2005-09-15 19:42:27 CEST
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:

Thanks for your contribution.

Bug #1141

Reported by:
Ian Morgan
Reported on: 2005-09-08
Last modified on: 2009-07-14


Olivier Fourdan
CC List:
0 users



Additional information