On 06/11/2010 10:02 PM, Michiel de Hoon wrote:
>> I agree that the difference in blocking behavior is still a
>> problem. I think that what we should do for now, *if* multiple
>> calls to show work on the Mac (which I can't easily test), is
>> change the documentation to correspond to the present situation,
>> highlighting the real problem of different blocking behavior.
>
> On Mac OS X, the MacOSX native backend supports multiple calls to show(). 
> Each call to show() blocks, and show() returns when all figures are closed by 
> the user.
>
OK, so this sounds like the standard blocking behavior, just like gtk*, 
wx*, and qt* on Linux.

> With TkAgg on Mac OS X, the first call to show() blocks, and returns when all 
> figures are closed by the user. However, subsequent calls to show() return 
> immediately.
>

This is anomalous, then; on linux, no call to show blocks with tkagg. 
Puzzling difference.

> With GtkCairo on Mac OS X, each call to show() blocks, so show() can be 
> called repeatedly. However, after closing all windows, show() does not return 
> unless the user presses ctrl-c. This may not be so difficult to fix though. 
> Basically, we need to keep track of how many windows are open at any given 
> point, and tell the GTK main loop to exit when the number of windows reaches 
> zero (this is how the MacOSX native backend does it).
>

I wasn't even aware of this backend; but sure enough, I have it on 
linux, and it works the same as gtkagg et al.

Why would it behave differently on OS X, with the need for the ctrl-C?

If you have TkAgg and GtkCairo, does it mean you also have GtkAgg?  If 
so, I would expect it to behave like GtkCairo.

Thanks for the testing.

Eric


> --Michiel.
>
>
>


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to