Update of bug #20068 (project mypaint):
Status: Ready For Test => Need Info
_______________________________________________________
Follow-up Comment #11:
If the grab result was GDK_GRAB_ALREADY_GRABBED and gdk_pointer_is_grabbed()
returned False, it's some other app on your system grabbing the pointer.
That's... odd. Does this always happen around window switches?
Lots of questions now; sorry!
The current code absolutely shouldn't _hang_ the application in any way now.
The drag should now _not_ start and the cursor should _not_ change to the
"active" state (which for Pan View is a closed hand with a green and white
icon next to it) when the grab fails.
* Do you see the drag start at all? As in, does it start panning regardless?
* If so, do you end up _stuck_ in the drag when you release the button?
* And do you see the closed hand, or the open one?
Even in the grab-failed state, you should be able to activate menus, switch to
other modes in the toolbar, or use the mode you're just in (grabs
permitting!).
* Can you do any of these when it happens?
You might end up switched to the mode you just activated with the button after
the grab has been refused, but you should then be able to actually use the
mode with another pointer down - drag - pointer up.
* If you do end up in the mode - in its passive state - can you
click-drag-release and get a useful drag, or does it refuse the grab each time
you try?
And as ever...
* What window manager/DE are you using, OOI? Still using Wheezy/testing?
We may just have to shrug our shoulders and try to make it less irritating
when grabs do fail. Hence all the app behaviour questions! Thanks for testing.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?20068>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Mypaint-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-bugs
