Steve Chaplin a =E9crit :
> What situation would yield an "Xlib async reply"?
using your mt module:
>>> import mt
>>> mt.gui_cmd('print "OK"')
>>> import matplotlib
>>> import pylab
Xlib: unexpected async reply (sequence 0x4b)!
This is on linux, I don't know what you get on other platforms, but I=20
guess it's just as bad.
> How does it break method calls of matplotlib objects? In interactive
> mode the gtk backend does not work (by itself) so there's nothing to
Well, it depends on how ambitious you are :-)
> When thinking about using threads for interactive mode I had been
> assuming people using the interactive mode would be using the pylab
> interface, does anyone use the matplotlib class interface in interactiv=
I sometimes do. However, I've painted the situation worse than it is. I=20
almost only use the setter/getter methods, which are not dangerous.
One annoying thing though: error_msg will hang the gui:
>>> import mt
>>> mt.gui_cmd('from pylab import *')
*** gui hangs here, you get the prompt back, but no gui commands will=20
> In import_gtk() there is time.sleep(1) - what is that for?
This is an attempt to avoid a race condition were a proxy function would=20
be called before the GTK thread is initialized. I don't know if this=20
would lead to a real problem. 1s wait not that bad anyway.
> Shouldn't widget creation be protected as well by wrapping things like
> new_figure_manager() and FigureCanvasGTK(). I know __init__ is wrapped
> but objects may have __new__ methods which call gdk/gtk functions befor=
> __init__ is called.
I didn't think of that. Most GTK object are not dangerous until they are=20
> How about if a widgets standard methods such as show(), present() etc
> are used - they are not protected (unless called from a protected
> method). I think this just applies to using the class interface in
> interactive mode, so it may be rarely encountered but might be a
As I stated, I didn't try to protect methods inherited from GTK objects=20
(ie not defined in matplotlib). Which means people using them are on=20
their own. You have to draw the boundary somewhere, unless you want to=20
implement a full gui_thread.
> Why use gtk_protect(), exec() and GTK_TEMPLATE, when you could use:
> def gtk_protect (fun):
> def decorator (*args, **kwargs):
Well this was a try to set the proxy function name as the real function=20
name, in order to avoid weirdeness when reading object help. But I could=20
not set the argument spec correctly, so I ended up adding the 'proxy=20
from' line to the docstring. So I think all the GTK_TEMPLATE machinery=20
serves no purpose now.
As a final note, I have to say that the latest version of interactive.py=20
is good enough for my needs, so I'm no longer very motivated for pushing=20
If you just need the pylab interface, you can also do it without=20
patching matplotlib. Just create a protected_pylab.py module, where you=20
would start the gui thread, define the gtk_protect function, import=20
pylab and define command=3Dgtk_protect(pylab.command) for every command i=
pylab. Then doing 'from protected_pylab import *' would give you a=20
working pylab interface, with just the error_msg problem.