Hello,
here is a proposition of a new strategy for interactive plotting in GTK (probably also WX), that doesn't need IPython, and runs the mainloop in a separate thread from the calculations.
It has no impact on the user unless he chooses to make use of it, and a small impact on the backend developper.
It works in two parts:
matplotlib/__init__.py imports a gtk_protect function that returns a wrapper around "dangerous" functions or methods.
The one proposed here (protect_mutex.py) encloses the actual function call in a gtk.threads_enter() / gtk.threads_leave() pair in order to acquire the GTK mutex.
The same strategy seems possible in WX, though I encountered a lot of annoying little problems with WX 2.4. If someone is interested in taking over that part, please ask me (I usually don't use WX).
For the non-interactive case, matplotlib defines a dummy gtk_protect function which returns its own input, i.e. nothing is changed in that case.
Then all the backend as to do is call gtk_protect on dangerous functions or methods in order to replace them with a wrapper. The wrapper has little overhead, so I may have protected more than needed.
How to use:
after applying the patch, you have to change your rc params to actually use it. Change your .matplotlibrc to contain the following:
backend : GTKAgg # or GTK or GTKCairo
interactive : True
gui_protect : Mutex
Afterwards, you can run most of the examples with python -i, and modify the plots to your liking 
Cheers,
BC
gui.diff (18.9 KB)
Hello,
here is an imporved version of the patch (minor bug corrected + diffed against latest CVS).
By the way, it looks like the web interface is cutting off the patch. Probably the right thing given its size. Providing a link to the attached file would be nicer, though...
Cheers,
BC
gui.diff (18.1 KB)
Baptiste Carvello wrote:
Hello,
here is an imporved version of the patch (minor bug corrected + diffed against latest CVS).
Just a note: are you aware of the gui_thread module in scipy? It was written exactly to do this (though it's currently WX-specific, I think), and it has seen a pretty extensive amount of work. I would much rather see a generic, external solution be tested and improved than a matplotlib-specific rather intrusive patch. Don't take it badly, I can tell you've put a lot of work into this, but this kind of problem is IMHO best addressed by a more generic mechanism. The kind of attribute access which python allows opens the door for such a solution, as gui_thread has shown.
gui_thread currently needs testing and improvements, but I think in the long run it is a cleaner, better alternative.
Just my 2 cents.
Cheers,
f
Hello,
I'm just making a proposal. As long as the documentation points to IPython for interactive use, you can't say we have a perfect solution on our own 
(this is not meant to criticize your work on IPython, it's just that I feel more confortable with the usual python interface)
I know the patch is intrusive, though maybe not as much as it looks (everything except protect_mutex.py is pretty trivial). I didn't expected it to be accepted right away, I see it more as a contribution to the whole gui thread discution.
As for gui_thread, I looked at it last year, I just remember I didn't like that code that much. Maybe I should get another look...
Cheers,
BC
Fernando Perez a écrit :
···
Just a note: are you aware of the gui_thread module in scipy? It was written exactly to do this (though it's currently WX-specific, I think), and it has seen a pretty extensive amount of work. I would much rather see a generic, external solution be tested and improved than a matplotlib-specific rather intrusive patch. Don't take it badly, I can tell you've put a lot of work into this, but this kind of problem is IMHO best addressed by a more generic mechanism. The kind of attribute access which python allows opens the door for such a solution, as gui_thread has shown.
gui_thread currently needs testing and improvements, but I think in the long run it is a cleaner, better alternative.
Just my 2 cents.
Cheers,
f
Baptiste Carvello wrote:
Hello,
I'm just making a proposal. As long as the documentation points to IPython for interactive use, you can't say we have a perfect solution on our own (this is not meant to criticize your work on IPython, it's just that I feel more confortable with the usual python interface)
I know the patch is intrusive, though maybe not as much as it looks (everything except protect_mutex.py is pretty trivial). I didn't expected it to be accepted right away, I see it more as a contribution to the whole gui thread discution.
As for gui_thread, I looked at it last year, I just remember I didn't like that code that much. Maybe I should get another look...
I actually didn't have ipython in mind at all in my comment. I agree that a generic, shell-independent solution is a good thing to have. I just think that gui_thread provides a cleaner approach (if not clean code to the overall problem. gui_thread is messy, but it allows general (meaning, beyond matplotlib) access to gui elements from a command line. I quickly tested it with matplotlib and it crashed, so there's work to be done...
I was just trying to point out an alternate direction, ultimately if John is happy with this approach, it's his call (he gets to maintain it
Cheers,
f