Re: Nasty user mouse/keyboard move & resizing bugs from pointer warping

[Elijah Newren <newren gmail com>]

On 10/27/05, BJörn Lindqvist <bjourne gmail com> wrote:
> > We have four options, as far as I can tell:
> >   (1) Decide that the approximate fix-ups are good enough (check out
> >       the constraints_experiments branch if you want to play around with
> >       it, but be warned that there are other important regressions and
> >       bugs in that branch).
> >   (2) Stop warping the pointer (possibly hide it and show a fake
> >       pointer instead)
>
> I wonder if the pointer needs to be moved at all. "Where did my mouse
> go?!?" Otherwise I think a fake mouse pointer would be very nice
> because it neatly solves the problem with the mouse having to be moved
> back to its original position when the user aborts the mouse grab. A
> bug needs to be filed about that.

Yeah, I've been bothered a number of times by the pointer warping when
I wasn't using the mouse at all.  I'd love to fix this issue
too--though I think we may want the mouse to still be warped in some
cases (e.g. if the user is moving the window and moves it far enough
and the pointer was in the window to begin with).

> >   (3) Find a way to warp the pointer in a way that doesn't generate
> >       mouse events (i.e. not with XWarpPointer() as we currently do)
>
> Maybe it is possible to:
>
> 1. Stop listening to MotionNotify
> 2. XWrapPointer()
> 3. Restart listening to MotionNotify.
>
> So that the artificial MotionNotify events are not seen?

I tried thinking of a way to approximate that by somehow tracking the
MotionNotify events that we are likely to cause with the
XWrapPointer() but I couldn't figure out any robust way of doing so. 
Also, note that stop listening altogether could also cause problems
since we may get the MotionNotify from our XWrapPointer() call long
after getting MotionNotify events from real mouse motion... in fact,
this remaining bug that I sent this email about occurs precisely
because we do get the MotionNotify events corresponding to an
XWrapPointer() long after we get several more KeyPress events.

I'd like to do this, but I don't see how it's possible with X.  If
anyone knows better than me, I'd love to hear it.

> >   (4) Make keyboard and mouse moving/resizing orthogonal--after the
> >       user move/resize operation has started (e.g. due to pressing
> >       Alt+F7 or Alt+F8), allow either keyboard or mouse events to
> >       trigger updates, but as soon as one kind of event has happened
> >       ignore all events of the other kind (except maybe stuff to end
> >       the grab_op, such as hitting the Escape key or clicking).
>
> I think that sounds good too, but not as good as somehow getting rid
> of XWrapPointer (or its bad events) altogether. And would it solve the
> issue with shift+moving the mouse? Because surely the reason why
> shift-moving windows with the mouse doesn't work can't be keyboard
> events interfering?

I'm not sure what you are referring to with the "issue with
shift+moving" the mouse, but I fixed one or two such issues on the
constraints_experiments branch.  Could you try it out and let me know
if the problem you're referring to is still an issue with that
version?  (standard disclaimer: the constraints_experiments branch has
a number of other known regressions that you may run across, no need
to file zillions of bugs about them yet)