Re: [matplotlib-devel] Another try at interactive gui thread

[Baptiste C. <bap...@al...>]

Steve Chaplin a =E9crit :
> Regarding Baptiste's patch
> - I'm not too keen on the idea of wrapping gtk.gdk.threads_enter() /
> gtk.gdk.threads_leave() around every GDK function call.
> - I share Fernando's concern with possible problems when adding new
> widgets or embedding a matplotlib window into something else.
>=20
> My understanding is that wrapping gtk.gdk.threads_enter() /
> gtk.gdk.threads_leave() around GDK functions is not necessary if all th=
e
> GDK calls occur in the same thread. So I think a simpler solution is to
> arrange for all gui calls to go to a single thread and do away with
> enter()/leave().
>=20
This is mostly a question of taste.
A bug in the handling of threads_enter()/threads_leave() leads to a=20
deadlock, while a bug with a gui thread yields "Xlib async reply".=20
Choose which ugly death you prefer !

> I created a module that allows interactive matplotlib access from a
> python shell, its a modified version of
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109
>=20
In fact your module fits well into the framework of my proposal: all you=20
have to do is rename your gui_cmd to gtk_protect, and change a few=20
things like passing the function directly, passing the arguments, and=20
returning the value. Then you will have a drop-in replacement for=20
protect_mutex.py.

> This method seems to work for me (on Linux) and is not very intrusive t=
o
> matplotlib code - it just requires that 'gui_cmd()' is used to execute
> all gui commands when in interactive mode.
>=20
This is where the real beef is.
There are several strategies:
* wrap everything: this is the examples/interactive.py strategy, simple,=20
but the gui freezes on long calculations
* wrap all gui calls: this is the gui_thread strategy: elegant, but=20
difficult
* wrap only pylab functions (draw_if_interactive etc), as you seem to=20
suggest in your second email: imho this is not acceptable because it=20
breaks method calls of matplotlib objects
* draw the line somewhere in the backend: this is what I proposed.

In the end, the backends developpers have the final say, because they=20
will have to do the day-to-day maintenance.

> Any comments?
>=20
> Regards
> Steve
>=20
Cheers, BC

PS: tell me if I need to CC you or not