matplotlib-devel Mailing List for matplotlib

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

>>>>> "Baptiste" == Baptiste Carvello <bap...@al...> writes:
 Baptiste> Hello, I tried to improve the way of plotting two scales
 Baptiste> (cf examples/two_scales.py). The attached patch contains
 Baptiste> the following changes:
Hi Baptiste -- I applied your patch and am very impressed. It takes a
lot of hacking through matplotlib internals to get everything working
right together with transform, axis limits and the like. Your
approach is also a significant improvement over what we currently
have.
Here is what I think would be ideal, and I wanted to sketch some of
these ideas in hopes that you might have some ideas on how to apply
them. Basically, the idea is that we want one axes to be able to
share the x or y limits with another axes in a more general way. Your
approach works fine as long as the two axes are overlayed. It would
be nice if we could do something like
 # separate axes
 ax1 = subplot(211)
 plot([1,2,3])
 ax2 = subplot(212, twinx=ax1)
 plot([4,5,6])
To do overlayed axes, you could do
 # overalyed axes
 ax1 = subplot(111)
 plot([1,2,3])
 ax2 = subplot(111, twinx=ax1, yticks='right')
 plot([4,5,6])
I think this would be a nice consistent interface and in both cases
ax2 would share the xlim with ax1. As far as I can see, the only
thing getting in the way of extending your approach to handle this
case are the tick labels, since they would be in the wrong place for
ax2 in the separate axes case. For the separate axes case, you would
typically want tick labeling on the lower axes, but it would be ideal
to be able to control that as well.
I've been meaning to decouple the axis line and tick locations from
the main axes frame so that you could have offset labels and ticks.
Perhaps this would be a good time to make both changes together.
The other problem in the current implementation (and in your patch)
stems from the fact that for event handling, only one axes gets the
event. So in your two_scales.py example, if you pan/zoom the xlimits
behave correctly but only one axes gets the pan/zoom event for y. It
would be nice to pass these events on to all the axes the user is over
to handle the case of overlapping axes.
Just some thoughts on what I think the proper behavior should be. If
you have any ideas on how to handle these, let me know. 
I just applied your two scales patch to CVS as an improved interim
solution.
Thanks!
JDH

On Wed, 2005年01月26日 at 12:17 +0800, Steve Chaplin wrote:
> 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
> 
> This method seems to work for me (on Linux) and is not very intrusive to
> matplotlib code - it just requires that 'gui_cmd()' is used to execute
> all gui commands when in interactive mode.
I may not have clearly explained my idea. I'm not proposing another
Python shell/interpreter to run matplotlib. The mt.py module is to test
an idea without needing to modify any matplotlib code. 
To use it as intended would involve moving it into matplotlib and
getting matplotlib to call gui_cmd() to execute interactive gtk/gdk
calls in their own thread.
This is the part I'm not sure about - what is the minimal set of
functions to wrap with gui_cmd() to ensure that it encloses all gtk/gdk
functions?
gui_cmd() could be called from draw_if_interactive() and maybe
new_figure_manager(), I'm not sure where else it might be needed.
Also it would need to be fed import commands.
Steve

Steve Chaplin wrote:
> 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
> 
> This method seems to work for me (on Linux) and is not very intrusive to
> matplotlib code - it just requires that 'gui_cmd()' is used to execute
> all gui commands when in interactive mode.
> 
> Any comments?
In case anyone is interested, here's a lightweight, standalone (non-ipython) 
GTK threaded interactive interpreter with matplotlib support. This code is 
also based on the same ASPN recipe, it's basically the prototype I used to 
understand that recipe when I was adding the matplotlib support to IPython.
The threading tricks are the gold in that recipe, but the rest of the code is 
rather messy. I pretty much rewrote it when studying it (while keeping the 
threading core). Perhaps this may be of use to others. The ASPN recipe 
duplicates a lot of the functionality in the code.py module from the standard 
library, which is completely unnecessary (it's guaranteed to be there in any 
python installation). By using code.py, the whole thing can be rewritten much 
more cleanly (and you benefit from a good implementation in the stdlib for all 
the interpreter emulation parts).
I think I sent this to John a while back so he could replace the 
interactive.py shipped with matplotlib. I fully acknowledge in the header the 
ASPN recipe as the origin of the threading solution.
The pylab support in current ipython is basically this same idea, but 
generalized to work with either GTK or WX, and blended into the IPython code 
structure (that wasn't too bad, since ipython itself is based on code.py).
Cheers,
f

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.
My understanding is that wrapping gtk.gdk.threads_enter() /
gtk.gdk.threads_leave() around GDK functions is not necessary if all the
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().
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
This method seems to work for me (on Linux) and is not very intrusive to
matplotlib code - it just requires that 'gui_cmd()' is used to execute
all gui commands when in interactive mode.
Any comments?
Regards
Steve