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

I agree, I don't think the pointer should be warped at all during keyboard-initiated window resize/move. Perhaps warping the pointer at the end of the process makes sense, i.e when all relevant modifier keys have been released, but I am not sure. In any case if it makes the modifier grabs more complex I'd say "don't do it", as grabs on unshifted modifiers are very evil (they break accessibility, see bug


BJörn Lindqvist 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.

 (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?

 (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?

mvh Björn
metacity-devel-list mailing list
metacity-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]