Follow-up Comment #6, bug #17650 (project mypaint):
Setting a wait cursor everywhere, for real - For Really Real! - needs a (GDK,
i.e. X11) pointer grab on my system. However, this locks out all other apps on
the user's X display, and I don't think that's at all acceptable for loading
and saving.
Annoyingly, if you try and set a cursor on all of the user's current set of
toplevel gdk.Windows, it only actually takes effect for the *current* toplevel
and everything in it. Looks like this is a GDK limitation on my system anyway:
you're limited to just the current X11 window and its descendants for this.
Setting the cursor on the root window blows away the user's cursor theme.
Let's not do that.
BTW, Jonnor: I notice that the user can still interact with the UI in some
ways during a slow load or save. The events get delivered after the slow
task's finished. I've had a play with with_wait_cursor(), and establishing a
GTK (not GDK) widget grab on the main window, with an event mask of 0 forced
for its corresponding gdk.Window. This helps suppress events to the rest of
the app. Obviously you undo this on the way out of the slow-running part...)
It looks like the only way we're going to get sane cursor behaviour here for
all windows is to do the long-running thing in a subthread of its own, leaving
the main loop free to process certain GTK events: enter notifies, specifically
- ideally with everything else masked off using the hack above until the
subthread terminates. You do the cursor setting as the pointer enters each
sub-window... yuck.
Might be worth investigating save/load threads though: would it allow us to
set up some form of background saving later, maybe?
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?17650>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Mypaint-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-bugs
