matplotlib-devel Mailing List for matplotlib

Hi,
No more traceback with the matplolib cvs version.
However, I observe now some strange behavior.
I join a new example code.
 When you launch the script and press replot button (circle should become a
line in both tab), then switch to the second tab everything ok. But back to
the first tab and press replot (line should become a circle in both tab),
switch to the second tab... still see a line. If you use the "pan" tool in
the toolbar and move a bit the graph then the figure is the updated and
become a circle.
Regards,
David
2006年2月20日, Steve Chaplin <ste...@ya...>:
>
> On Sun, 2006年02月19日 at 22:09 -0800,
> mat...@li... wrote:
> > Here is a quick and dirty minimal code reproducing the problem.
> >
> > David
> [snip ...]
>
> It is slightly obscure - why would you write a callback to display an
> widget in a notebook tab which is not visible? However, the
> FigureCanvasGTK should be able to handle this case so it is a bug.
>
> The problem is with the "canvas2.draw()" line.
> When you run the test the second canvas widget is not immediately
> displayed, so it does not get realized() and its gdk.Window has not been
> created which causes problems with code which uses the gdk.Window. The
> expose_event() code checks for this case with
> if GTK_WIDGET_DRAWABLE(self):
> but FigureCanvasGTK.draw() was missing this check.
>
> Its fixed now in CVS (I also simplified the draw() code a little).
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Here it goes again. And sorry for the delay, I was busy with other 
things, will catch up...
Yes, I believe it does not conflict with the savefig's 
landscape-vs-portrait handling. Some of the EPS viewers need this flag 
in order to show the plot in its original orientation (read: heads up).
In addition, I find the code in lines 1049-1053 of bakend_ps.py somewhat 
strange: in my understanding, landsape means that the plot's "up" 
direction is oriented to the left, i.e., the plot is rotated 90CCW. This 
has nothing to do with the plot's width and height. However, that's not 
my code I wouldn't like to fix that myself without knowing the original 
author's intent. Comments?
-- Alex
Index: lib/matplotlib/backends/backend_ps.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_ps.py,v
retrieving revision 1.81
diff -r1.81 backend_ps.py
1054a1055,1056
 > else:
 > print >>fh, "%%Orientation: Portrait"

Thanks for the fix. I'll try the CVS version ASAP.
The small example I sent was just to reproduce the problem.
I was not able to trace the problem myself as I'm a just a poor scientist
and not a software engineer (even if I like programming)
To make my need a bit more clear:
Roughly, I have a notebook to display my data 3 different ways, each in one
notebook tabs.
Data processing is controlled in the first notebook so after changes I have
to update the plots in the others tabs.
I could update the plot each time I make a tab visible but it will
unnecessarily slow down the switching in between tabs.
Again thank you very much for your help.
And thanks to all matplotlib developers for their great work!
Hope, Numpy/Scipy/Matplotlib/Pytables/Pyvisa/pygtk will attract more and
more users.
I strongly suggest all scientist to try this combination, it's amazingly
powerful.
David
2006年2月20日, Steve Chaplin <ste...@ya...>:
>
> On Sun, 2006年02月19日 at 22:09 -0800,
> mat...@li... wrote:
> > Here is a quick and dirty minimal code reproducing the problem.
> >
> > David
> [snip ...]
>
> It is slightly obscure - why would you write a callback to display an
> widget in a notebook tab which is not visible? However, the
> FigureCanvasGTK should be able to handle this case so it is a bug.
>
> The problem is with the "canvas2.draw()" line.
> When you run the test the second canvas widget is not immediately
> displayed, so it does not get realized() and its gdk.Window has not been
> created which causes problems with code which uses the gdk.Window. The
> expose_event() code checks for this case with
> if GTK_WIDGET_DRAWABLE(self):
> but FigureCanvasGTK.draw() was missing this check.
>
> Its fixed now in CVS (I also simplified the draw() code a little).
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.co=
m
>
>

On Sun, 2006年02月19日 at 22:09 -0800,
mat...@li... wrote:
> Here is a quick and dirty minimal code reproducing the problem.
> 
> David
[snip ...]
It is slightly obscure - why would you write a callback to display an
widget in a notebook tab which is not visible? However, the
FigureCanvasGTK should be able to handle this case so it is a bug.
The problem is with the "canvas2.draw()" line.
When you run the test the second canvas widget is not immediately
displayed, so it does not get realized() and its gdk.Window has not been
created which causes problems with code which uses the gdk.Window. The
expose_event() code checks for this case with 
 if GTK_WIDGET_DRAWABLE(self):
but FigureCanvasGTK.draw() was missing this check.
Its fixed now in CVS (I also simplified the draw() code a little).
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com