matplotlib-devel Mailing List for matplotlib (Page 3)

I have a student here trying to make a webapp for data reduction.  To add
interactivity, we've been using the FLOT package, and may later consider
protovis.  We had thought about making a javascript backend for MPL, but to
just get something running, we went with FLOT for the time being...We're
using EXTJS as the web framework (it's a bit heavy, but has a rich widget
toolkit and documentation).  We use Django on the backend and Orbited to
deal with some communications between the browser and the server (for
example if we get new data from an instrument and want to update it on the
server and update plots that are viewing that data..).  Over the next couple
of weeks (with the arrival of another student), we will be working more with
the plotting aspect of the project (adding legends, zooming, etc).   Also,
for other parts of the app, we're just using the HTML5 canvas...I'd be happy
to work on making the plotting addons as generic as possible so they can be
used outside of our problem domain.  What I'm not sure is whether one wants
to truly use MPL as a backend, or rather to use the MPL philosophy of a
javascript package.

Cheers,
William

On Wed, Jun 16, 2010 at 6:45 PM, Andrew Straw <str...@as...> wrote:

> Hi Ondrej,
>
> If I was in your shoes, the first thing I'd do is emit your data to plot
> as a json object and then plot that data using javascript with one of
> the libraries you've listed. Then, after gaining some familiarity with
> Python->json->javascript I'd think about how such an MPL backend might
> work. A usecase I could imagine is some Django app that uses MPL to plot
> stuff into a javascript canvas element complete with zooming and so on.
>
> I think there are a lot of open questions in this domain... For example,
> presumably one doesn't want the server involved when the client browser
> zooms. But then if you implement something that allows the client
> browser to zoom without the server MPL process, you're no longer using
> the normal MPL callback system. So, interactivity would probably be
> different than in the traditional backends.
>
> You could also start with the svg backend, as browsers do render svg.
>
> -Andrew
>
> Ondrej Certik wrote:
> > Hi,
> >
> > could someone please point me to the latest status of the web gui?
> >
> > I am now in LLNL and I don't have a root access to my computer
> > (running rhel5), and there is no Tk, nor Tkinter Python modules. I
> > have installed femhub, so I have the whole python stack, but I don't
> > have any gui. Mpl can save figures to a file, so at least something.
> > But I am missing the zoom feature.
> >
> > I found the following cool libraries:
> >
> > http://www.sencha.com/
> > http://raphaeljs.com/
> > http://g.raphaeljs.com/
> >
> > that work perfectly in my browser (FF3). So I wondered how hard it
> > would be to use them as an mpl backend? All I need, I think, is just
> > simple plotting, and zoom (+pan).
> >
> > I could adapt for example:
> >
> > lib/matplotlib/backends/backend_tkagg.py
> >
> > but it seems quite involved. Is there some simple thing, that would
> > "just work" for me, that I could start adapting for the web gui? I
> > would imagine that show() would launch a web server and tell the user
> > to go to localhost:8080 or something and then the gui would be in the
> > browser. The browser can even be opened automatically.
> >
> > Ondrej
> >
> >
> ------------------------------------------------------------------------------
> > 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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi Ondrej,

If I was in your shoes, the first thing I'd do is emit your data to plot
as a json object and then plot that data using javascript with one of
the libraries you've listed. Then, after gaining some familiarity with
Python->json->javascript I'd think about how such an MPL backend might
work. A usecase I could imagine is some Django app that uses MPL to plot
stuff into a javascript canvas element complete with zooming and so on.

I think there are a lot of open questions in this domain... For example,
presumably one doesn't want the server involved when the client browser
zooms. But then if you implement something that allows the client
browser to zoom without the server MPL process, you're no longer using
the normal MPL callback system. So, interactivity would probably be
different than in the traditional backends.

You could also start with the svg backend, as browsers do render svg.

-Andrew

Ondrej Certik wrote:
> Hi,
>
> could someone please point me to the latest status of the web gui?
>
> I am now in LLNL and I don't have a root access to my computer
> (running rhel5), and there is no Tk, nor Tkinter Python modules. I
> have installed femhub, so I have the whole python stack, but I don't
> have any gui. Mpl can save figures to a file, so at least something.
> But I am missing the zoom feature.
>
> I found the following cool libraries:
>
> http://www.sencha.com/
> http://raphaeljs.com/
> http://g.raphaeljs.com/
>
> that work perfectly in my browser (FF3). So I wondered how hard it
> would be to use them as an mpl backend? All I need, I think, is just
> simple plotting, and zoom (+pan).
>
> I could adapt for example:
>
> lib/matplotlib/backends/backend_tkagg.py
>
> but it seems quite involved. Is there some simple thing, that would
> "just work" for me, that I could start adapting for the web gui? I
> would imagine that show() would launch a web server and tell the user
> to go to localhost:8080 or something and then the gui would be in the
> browser. The browser can even be opened automatically.
>
> Ondrej
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

On 06/16/2010 12:06 PM, Ondrej Certik wrote:
> Hi,
>
> could someone please point me to the latest status of the web gui?
>
> I am now in LLNL and I don't have a root access to my computer
> (running rhel5), and there is no Tk, nor Tkinter Python modules. I
> have installed femhub, so I have the whole python stack, but I don't
> have any gui. Mpl can save figures to a file, so at least something.
> But I am missing the zoom feature.
>
> I found the following cool libraries:
>
> http://www.sencha.com/
> http://raphaeljs.com/
> http://g.raphaeljs.com/
>
> that work perfectly in my browser (FF3). So I wondered how hard it
> would be to use them as an mpl backend? All I need, I think, is just
> simple plotting, and zoom (+pan).

I doubt that you could make zoom/pan fast while going through a web 
interface, without substantial changes to mpl.

As an alternative, can you install gtk and pygtk from tarballs, in 
locations you control?  I haven't tried it, so I have no idea how 
painful it would be; but if it works, you would have a fully-functional mpl.

Actually, on RH, I'm sure the gtk libraries are already there, so it 
would be a question of whether the -devel rpms are also installed.  If 
so, all you need would be pygtk, and that should be easy.

I presume you have already tried to get IT support to install things 
like pygtk.

Eric

>
> I could adapt for example:
>
> lib/matplotlib/backends/backend_tkagg.py
>
> but it seems quite involved. Is there some simple thing, that would
> "just work" for me, that I could start adapting for the web gui? I
> would imagine that show() would launch a web server and tell the user
> to go to localhost:8080 or something and then the gui would be in the
> browser. The browser can even be opened automatically.
>
> Ondrej
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

could someone please point me to the latest status of the web gui?

I am now in LLNL and I don't have a root access to my computer
(running rhel5), and there is no Tk, nor Tkinter Python modules. I
have installed femhub, so I have the whole python stack, but I don't
have any gui. Mpl can save figures to a file, so at least something.
But I am missing the zoom feature.

I found the following cool libraries:

http://www.sencha.com/
http://raphaeljs.com/
http://g.raphaeljs.com/

that work perfectly in my browser (FF3). So I wondered how hard it
would be to use them as an mpl backend? All I need, I think, is just
simple plotting, and zoom (+pan).

I could adapt for example:

lib/matplotlib/backends/backend_tkagg.py

but it seems quite involved. Is there some simple thing, that would
"just work" for me, that I could start adapting for the web gui? I
would imagine that show() would launch a web server and tell the user
to go to localhost:8080 or something and then the gui would be in the
browser. The browser can even be opened automatically.

Ondrej

Hi,

The autoscaling might need a small fix for

hist(rand(100),bins=20,histtype="step",log=1)

Cheers,
Olle

On 06/13/2010 08:23 AM, Гузий Саша wrote:
> Hello,
>
> I recently updated matplotlib using macports, and it broke my plotting
> functions which plot date-value plots.
>
> The reason was that my locale.getpreferredencoding() returned empty
> string in
> cbook.py.
>
> changing the code to the following solved my problem
>
> # On some systems, locale.getpreferredencoding returns None,
> # which can break unicode; and the sage project reports that
> # some systems have incorrect locale specifications, e.g.,
> # an encoding instead of a valid locale name.
>
> try:
>      preferredencoding = locale.getpreferredencoding()
>      if preferredencoding.strip() == '':
>          raise ValueError
> except ValueError:
>      preferredencoding = None
> except ImportError:
>      preferredencoding = None
>
> sorry for disturbing you
> --
> Huziy Oleksandr
>

Thank you for the report.  I committed a modified version of your change 
in svn 8433.

Eric

Hello,

I recently updated matplotlib using macports, and it broke my plotting
functions which plot date-value plots.

The reason was that my locale.getpreferredencoding() returned empty string
in
cbook.py.

changing the code to the following solved my problem

# On some systems, locale.getpreferredencoding returns None,
# which can break unicode; and the sage project reports that
# some systems have incorrect locale specifications, e.g.,
# an encoding instead of a valid locale name.

try:
    preferredencoding = locale.getpreferredencoding()
    if preferredencoding.strip() == '':
        raise ValueError
except ValueError:
    preferredencoding = None
except ImportError:
    preferredencoding = None

sorry for disturbing you
--
Huziy Oleksandr

On 06/13/2010 07:39 AM, Daniel Welling wrote:
> Something that I have noticed:
> When using TkAgg (python 2.5, OSX/ppc, mpl 99.0), isinteractive()
> switches from False to True after the first call to show() (see below).
> When I switch back ends, e.g. to Qt4, this change does not happen until
> I do it myself through ion().  This was reproduceable on my intel mac,
> but since updating to 99.1.1 (from source rather than Fink), I've broken
> the Tk backend.  Hope this helps; it may be a naive observation.

Not naive at all--this is one of the odd, and I think very undesirable, 
aspects of present TkAgg show() behavior.  It is eliminated by my 
proposed change.

Eric

>
> In [2]: import matplotlib as mpl
>
> In [3]: mpl.use('TkAgg')
>
> In [4]: import pylab as plt
>
> In [5]: plt.isinteractive()
> Out[5]: False
>
> In [6]: plt.plot([0,1])
> Out[6]: [<matplotlib.lines.Line2D object at 0x1dee1f0>]
>
> In [7]: plt.show()
>
> In [8]: plt.isinteractive()
> Out[8]: True
>
>
> On Sun, Jun 13, 2010 at 9:36 AM, Michiel de Hoon <mjl...@ya...
> <mailto:mjl...@ya...>> wrote:
>
>     --- On Fri, 6/11/10, Eric Firing <ef...@ha...
>     <mailto:ef...@ha...>> 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.
>
>     I now tried the remaining backends on Mac OS X. With the Qt4Agg and
>     WxAgg backends, show() can be called repeatedly and blocks each
>     time. The FltkAgg backend shows the same behavior as Tkagg. The
>     implementation of show() in the FltkAgg backend uses the same
>     _needmain as TkAgg. If I remove the _needmain stuff, then show() can
>     be called multiple times with FltkAgg, blocking each time.
>
>     --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
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Something that I have noticed:
When using TkAgg (python 2.5, OSX/ppc, mpl 99.0), isinteractive() switches
from False to True after the first call to show() (see below).  When I
switch back ends, e.g. to Qt4, this change does not happen until I do it
myself through ion().  This was reproduceable on my intel mac, but since
updating to 99.1.1 (from source rather than Fink), I've broken the Tk
backend.  Hope this helps; it may be a naive observation.

In [2]: import matplotlib as mpl

In [3]: mpl.use('TkAgg')

In [4]: import pylab as plt

In [5]: plt.isinteractive()
Out[5]: False

In [6]: plt.plot([0,1])
Out[6]: [<matplotlib.lines.Line2D object at 0x1dee1f0>]

In [7]: plt.show()

In [8]: plt.isinteractive()
Out[8]: True


On Sun, Jun 13, 2010 at 9:36 AM, Michiel de Hoon <mjl...@ya...>wrote:

> --- On Fri, 6/11/10, Eric Firing <ef...@ha...> 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.
>
> I now tried the remaining backends on Mac OS X. With the Qt4Agg and WxAgg
> backends, show() can be called repeatedly and blocks each time. The FltkAgg
> backend shows the same behavior as Tkagg. The implementation of show() in
> the FltkAgg backend uses the same _needmain as TkAgg. If I remove the
> _needmain stuff, then show() can be called multiple times with FltkAgg,
> blocking each time.
>
> --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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

--- On Fri, 6/11/10, Eric Firing <ef...@ha...> 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.

I now tried the remaining backends on Mac OS X. With the Qt4Agg and WxAgg backends, show() can be called repeatedly and blocks each time. The FltkAgg backend shows the same behavior as Tkagg. The implementation of show() in the FltkAgg backend uses the same _needmain as TkAgg. If I remove the _needmain stuff, then show() can be called multiple times with FltkAgg, blocking each time.

--Michiel.


      

On 06/12/2010 08:12 PM, Michiel de Hoon wrote:
> So on Linux, show(block=True) blocks but show(block=False) doesn't? If matplotlib is in interactive mode, does show(block=True) still block? Because if matplotlib is in interactive mode, then the call to matplotlib.interactive(True) shouldn't make a difference, and I would expect show(block=True) and show(block=False) to behave the same way.
>

Except that with block=False there is that _needmain flag.  And as you 
noted earlier, it blocks the first time, but not after that.  Somehow, I 
had previously missed the fact that it did block on the first call, so I 
did not realize that the tkagg behavior was identical on linux and mac, 
as one would expect.

Eric

> --Michiel.
>
> --- On Sat, 6/12/10, Eric Firing<ef...@ha...>  wrote:
>
>> From: Eric Firing<ef...@ha...>
>> Subject: Re: [matplotlib-devel] repeated calls to show() are now OK?
>> To: "Michiel de Hoon"<mjl...@ya...>
>> Cc: "John Hunter"<jd...@gm...>, "matplotlib development list"<mat...@li...>
>> Date: Saturday, June 12, 2010, 11:32 PM
>> On 06/12/2010 05:37 AM, Michiel de
>> Hoon wrote:
>>> --- On Sat, 6/12/10, Eric Firing<ef...@ha...>
>> wrote:
>>>>> 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.
>>>
>>> If I remove the _needmain stuff in the show() function
>> in the TkAgg backend, then each call to show() blocks on Mac
>> OS X with the TkAgg backend, which (in my understanding) is
>> the desired behavior. I don't know the purpose of _needmain
>> in the show() function, other than to disallow multiple
>> calls to show().
>>>
>>> --Michiel.
>>>
>>
>> I committed a change to backend_tkagg that leaves the show
>> functionality exactly as it is at present, but that
>> facilitates testing of a simpler version that I think is
>> more consistent with the other backends and with what we
>> want.  (I have appended the whole function to this
>> message--see below for additional explanation.)
>>
>> I have also done some more exploration and testing, and
>> here are my tentative conclusions:
>>
>> 1) We should aim for a show() that blocks until all windows
>> are closed, on all backends, and in all environments.
>> I think this is clearly something that many users would
>> like; it has reasonable use cases; and it is simple,
>> consistent, and easy to explain.
>>
>> 2) The big problem is the "in all environments" part of
>> that statement.  We probably can't achieve the goal,
>> but I suspect that over the long term we can approach it,
>> and the result will be "good enough".
>>
>> 3) As a step in that direction, I would like to see enough
>> testing of Tk with show(block=True) so that, if it works, we
>> can transition towards that behavior as the default,
>> deprecate the old behavior, and eventually eliminate
>> it.  Presently, TkAgg is most anomalous among the major
>> backends.
>>
>> 4) Leaving the documentation (all in the FAQ) with its
>> caution against anything but a single show() at the end of a
>> script is fine for 1.0; supporting multiple calls to a
>> blocking show under mildly restrictive conditions is a
>> reasonable goal for a subsequent release.
>>
>> Eric
>>
>> ------------------------------------------------
>> def show(block=False):
>>      """
>>      Show all figures.
>>
>>      Temporary, experimental kwarg *block*
>> defaults to False to
>>      provide the behavior present throughout mpl
>> history to date:
>>      interactive mode is forced on, and show does
>> not block.
>>
>>      Set *block* to True to test the proposed new
>> behavior,
>>      consistent with other backends, in which show
>> does not affect
>>      interactive mode, and always blocks until all
>> figures are closed.
>>      In addition, the rcParam['tk.pythoninspect']
>> is ignored.
>>
>>      Use this kwarg only for testing; other
>> backends do not accept
>>      a kwarg to show, and might never do so.
>>      """
>>      for manager in Gcf.get_all_fig_managers():
>>          manager.show()
>>      if block:
>>          # proposed new behavior; seems
>> to make this backend consistent
>>          # with others, with no
>> drawbacks identified yet.
>>          Tk.mainloop()
>>      else:
>>          # long-time behavior:
>> non-blocking, forces interactive mode
>>          import matplotlib
>>          matplotlib.interactive(True)
>>          if
>> rcParams['tk.pythoninspect']:
>>
>> os.environ['PYTHONINSPECT'] = '1'
>>          if show._needmain:
>>              Tk.mainloop()
>>              show._needmain =
>> False
>>
>> show._needmain = True   # This can go away
>> if we eliminate block=False option.
>>
>>
>>
>
>
>

So on Linux, show(block=True) blocks but show(block=False) doesn't? If matplotlib is in interactive mode, does show(block=True) still block? Because if matplotlib is in interactive mode, then the call to matplotlib.interactive(True) shouldn't make a difference, and I would expect show(block=True) and show(block=False) to behave the same way.

--Michiel.

--- On Sat, 6/12/10, Eric Firing <ef...@ha...> wrote:

> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] repeated calls to show() are now OK?
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "John Hunter" <jd...@gm...>, "matplotlib development list" <mat...@li...>
> Date: Saturday, June 12, 2010, 11:32 PM
> On 06/12/2010 05:37 AM, Michiel de
> Hoon wrote:
> > --- On Sat, 6/12/10, Eric Firing<ef...@ha...> 
> wrote:
> >>> 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.
> > 
> > If I remove the _needmain stuff in the show() function
> in the TkAgg backend, then each call to show() blocks on Mac
> OS X with the TkAgg backend, which (in my understanding) is
> the desired behavior. I don't know the purpose of _needmain
> in the show() function, other than to disallow multiple
> calls to show().
> > 
> > --Michiel.
> > 
> 
> I committed a change to backend_tkagg that leaves the show
> functionality exactly as it is at present, but that
> facilitates testing of a simpler version that I think is
> more consistent with the other backends and with what we
> want.  (I have appended the whole function to this
> message--see below for additional explanation.)
> 
> I have also done some more exploration and testing, and
> here are my tentative conclusions:
> 
> 1) We should aim for a show() that blocks until all windows
> are closed, on all backends, and in all environments. 
> I think this is clearly something that many users would
> like; it has reasonable use cases; and it is simple,
> consistent, and easy to explain.
> 
> 2) The big problem is the "in all environments" part of
> that statement.  We probably can't achieve the goal,
> but I suspect that over the long term we can approach it,
> and the result will be "good enough".
> 
> 3) As a step in that direction, I would like to see enough
> testing of Tk with show(block=True) so that, if it works, we
> can transition towards that behavior as the default,
> deprecate the old behavior, and eventually eliminate
> it.  Presently, TkAgg is most anomalous among the major
> backends.
> 
> 4) Leaving the documentation (all in the FAQ) with its
> caution against anything but a single show() at the end of a
> script is fine for 1.0; supporting multiple calls to a
> blocking show under mildly restrictive conditions is a
> reasonable goal for a subsequent release.
> 
> Eric
> 
> ------------------------------------------------
> def show(block=False):
>     """
>     Show all figures.
> 
>     Temporary, experimental kwarg *block*
> defaults to False to
>     provide the behavior present throughout mpl
> history to date:
>     interactive mode is forced on, and show does
> not block.
> 
>     Set *block* to True to test the proposed new
> behavior,
>     consistent with other backends, in which show
> does not affect
>     interactive mode, and always blocks until all
> figures are closed.
>     In addition, the rcParam['tk.pythoninspect']
> is ignored.
> 
>     Use this kwarg only for testing; other
> backends do not accept
>     a kwarg to show, and might never do so.
>     """
>     for manager in Gcf.get_all_fig_managers():
>         manager.show()
>     if block:
>         # proposed new behavior; seems
> to make this backend consistent
>         # with others, with no
> drawbacks identified yet.
>         Tk.mainloop()
>     else:
>         # long-time behavior:
> non-blocking, forces interactive mode
>         import matplotlib
>         matplotlib.interactive(True)
>         if
> rcParams['tk.pythoninspect']:
>            
> os.environ['PYTHONINSPECT'] = '1'
>         if show._needmain:
>             Tk.mainloop()
>             show._needmain =
> False
> 
> show._needmain = True   # This can go away
> if we eliminate block=False option.
> 
> 
> 


      

On 06/12/2010 05:37 AM, Michiel de Hoon wrote:
> --- On Sat, 6/12/10, Eric Firing<ef...@ha...>  wrote:
>>> 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.
>
> If I remove the _needmain stuff in the show() function in the TkAgg backend, then each call to show() blocks on Mac OS X with the TkAgg backend, which (in my understanding) is the desired behavior. I don't know the purpose of _needmain in the show() function, other than to disallow multiple calls to show().
>
> --Michiel.
>

I committed a change to backend_tkagg that leaves the show functionality 
exactly as it is at present, but that facilitates testing of a simpler 
version that I think is more consistent with the other backends and with 
what we want.  (I have appended the whole function to this message--see 
below for additional explanation.)

I have also done some more exploration and testing, and here are my 
tentative conclusions:

1) We should aim for a show() that blocks until all windows are closed, 
on all backends, and in all environments.  I think this is clearly 
something that many users would like; it has reasonable use cases; and 
it is simple, consistent, and easy to explain.

2) The big problem is the "in all environments" part of that statement. 
  We probably can't achieve the goal, but I suspect that over the long 
term we can approach it, and the result will be "good enough".

3) As a step in that direction, I would like to see enough testing of Tk 
with show(block=True) so that, if it works, we can transition towards 
that behavior as the default, deprecate the old behavior, and eventually 
eliminate it.  Presently, TkAgg is most anomalous among the major backends.

4) Leaving the documentation (all in the FAQ) with its caution against 
anything but a single show() at the end of a script is fine for 1.0; 
supporting multiple calls to a blocking show under mildly restrictive 
conditions is a reasonable goal for a subsequent release.

Eric

------------------------------------------------
def show(block=False):
     """
     Show all figures.

     Temporary, experimental kwarg *block* defaults to False to
     provide the behavior present throughout mpl history to date:
     interactive mode is forced on, and show does not block.

     Set *block* to True to test the proposed new behavior,
     consistent with other backends, in which show does not affect
     interactive mode, and always blocks until all figures are closed.
     In addition, the rcParam['tk.pythoninspect'] is ignored.

     Use this kwarg only for testing; other backends do not accept
     a kwarg to show, and might never do so.
     """
     for manager in Gcf.get_all_fig_managers():
         manager.show()
     if block:
         # proposed new behavior; seems to make this backend consistent
         # with others, with no drawbacks identified yet.
         Tk.mainloop()
     else:
         # long-time behavior: non-blocking, forces interactive mode
         import matplotlib
         matplotlib.interactive(True)
         if rcParams['tk.pythoninspect']:
             os.environ['PYTHONINSPECT'] = '1'
         if show._needmain:
             Tk.mainloop()
             show._needmain = False

show._needmain = True   # This can go away if we eliminate block=False 
option.

--- On Sat, 6/12/10, Eric Firing <ef...@ha...> wrote:
> > 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.

If I remove the _needmain stuff in the show() function in the TkAgg backend, then each call to show() blocks on Mac OS X with the TkAgg backend, which (in my understanding) is the desired behavior. I don't know the purpose of _needmain in the show() function, other than to disallow multiple calls to show().

--Michiel.


      

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.
>
>
>

> 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.

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.

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).

--Michiel.


      

On 06/11/2010 10:09 AM, John Hunter wrote:
> On Fri, Jun 11, 2010 at 2:56 PM, Eric Firing<ef...@ha...>  wrote:
>
>> Is it time for us to change our documentation, and officially support
>> the use of multiple calls to show()?  If we can do it, I think it would
>> remove one of the main stumbling blocks for newcomers.
>
> I don't have a problem allowing/supporting it, but it may be tricky if
> we expect it to have the same blocking/non-blocking behavior across
> backends.  Ie, for the script that does
>
> for i in range(10):
>     plt.plot(np.random.rand(10), 'o')
>     plt.show()
>
> many users expect that to be blocking on each call to show and the
> script to continue after closing each figure.  My guess is that
> different backends on different platforms might show different
> behavior -- some may block, others not.  I haven't looked at your
> changes yet, but what is your opinion on this issue?

The only change I made was to the wx backend.  (The basic idea was 
provided in a patch submitted nearly 3 years ago.) All the other non-Mac 
backends already handled multiple calls to show.

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.

Longer term, the ideal would be to universally support both blocking and 
non-blocking behavior, since there are valid use-cases for each.  It 
would have to be coordinated with ipython.  I suspect it is easier to 
add a blocking option to the non-blockers than to give the blockers a 
non-block option.  I really don't know whether we are going to be able 
to make major progress on this, though.  Guis are a pain, and multiple 
gui toolkits interacting with multiple environments yield major pain and 
frustration.

Eric

>
> JDH

On Fri, Jun 11, 2010 at 2:56 PM, Eric Firing <ef...@ha...> wrote:

> Is it time for us to change our documentation, and officially support
> the use of multiple calls to show()?  If we can do it, I think it would
> remove one of the main stumbling blocks for newcomers.

I don't have a problem allowing/supporting it, but it may be tricky if
we expect it to have the same blocking/non-blocking behavior across
backends.  Ie, for the script that does

for i in range(10):
   plt.plot(np.random.rand(10), 'o')
   plt.show()

many users expect that to be blocking on each call to show and the
script to continue after closing each figure.  My guess is that
different backends on different platforms might show different
behavior -- some may block, others not.  I haven't looked at your
changes yet, but what is your opinion on this issue?

JDH

On 06/11/2010 09:09 AM, Michael Droettboom wrote:
> On 06/11/2010 02:38 PM, jas...@cr... wrote:
>> On 6/11/10 1:02 PM, Michael Droettboom wrote:
>>
>>>
>>>> It appears that the difficulty is that quantization is exposed at the
>>>> python level only for collections, via iter_segments.
>>>>
>>>>
>>>>
>>> Sort of.  Lines (but none of the other artists) follow what is set by
>>> "set_snap" (the use of two terms for the same thing is also a problem,
>>> of course).  This needs to be extended to other artists (and other
>>> relevant backend methods other than draw_path, if necessary).  But I
>>> think for convenience, it should also be a global rcParam.
>>>
>> I think a work-around, then (at least it seems to work for me), is
>> setting both snap to False and antialiased to False for the spines.
>> That won't solve the issue for other horizontal lines, but at least it
>> takes care of having the correct origin for the intersection of the
>> spines.  (Correct me if I'm wrong, of course!)
>>
>> from matplotlib import pyplot as plt
>> import numpy as np
>> fig = plt.figure()
>> ax = fig.add_subplot(1,1,1, aspect='equal')
>> line1=ax.plot([-1,1],[0,0], color='blue')
>> line2=ax.plot([-1,1],[-1,1], color='red',zorder=5)
>> ax.set_xlim(-1.1,1.1)
>> ax.set_ylim(-1.1,1.1)
>> ax.spines['left'].set_position('zero')
>> ax.spines['left'].set_snap(False)
>> ax.spines['left'].set_antialiased(False)
>> ax.spines['right'].set_color('none')
>> ax.spines['bottom'].set_position('zero')
>> ax.spines['bottom'].set_snap(False)
>> ax.spines['bottom'].set_antialiased(False)
>> ax.spines['top'].set_color('none')
>> ax.xaxis.set_ticks_position('bottom')
>> ax.yaxis.set_ticks_position('left')
>> fig.savefig('test.png',dpi=100)
>>
> I've committed a patch that provides a global snap setting in r8415.
> Set the rcParam "path.snap" to False to turn off all snapping (though it
> should be equivalent to your "set_snap" calls above -- just possibly
> more convenient).
>
> However, I think turning anti-aliasing off will give you the same
> problem at some scales, as anti-aliasing has basically the same effect
> as snapping: rounding to integral pixel values.  Try an odd dpi such as
> "67" for example.

I think you meant to say that aliasing is snapping, so with 
anti-aliasing off, aliasing is universal, and all points are snapped to 
pixels.

Eric

>
> Mike
>

It seems that every couple of weeks, someone understandably asks why one 
can't call show() more than once in a script or session.  However, I 
think that at least on all non-Mac backends, it now works.  I have 
tested it (using ipython, with no threading) on:

qtagg, qt4agg, wx, wxagg, gtk, gtkagg, tkagg, and fltkagg

The only glitch is what appears to be an unrelated bug in fltkagg: 
clicking on the window-kill button of a sole open window doesn't have 
any effect.

(There is also the difference in behavior: tkagg and fltkagg calls to 
show are non-blocking, while all the other backends block.)

What is the situation with respect to the Mac backends?

Is it time for us to change our documentation, and officially support 
the use of multiple calls to show()?  If we can do it, I think it would 
remove one of the main stumbling blocks for newcomers.

Eric

On 06/11/2010 08:03 AM, Michael Droettboom wrote:
> Wx, Gtk, Tk all work for me.  Couldn't test Qt "classic" as I don't have
> pyqt 3.x installed on my system.

I just now installed pyqt3 (after some thrashing around--it turns out 
one needs the python-qt-dev package on ubuntu), and verified that qt3agg 
passes the test.

Eric

>
> Mike
>
> On 06/11/2010 01:56 PM, Eric Firing wrote:
>> On 06/11/2010 07:44 AM, Michael Droettboom wrote:
>>
>>> The Qt4 backend crashes with a Segmentation Fault when no toolbar is
>>> requested. For example:
>>>
>> Mike,
>>
>> Have the other backends been tested for the same problem?
>>
>> Eric
>>
>>
>>> from matplotlib import pyplot as plt
>>> from matplotlib import rcParams
>>> rcParams['toolbar'] = 'None'
>>> fig=plt.figure()
>>> plt.show()
>>>
>>> I have attached a possible patch, but since I've never really touched
>>> the Qt4 backend before, thought I'd solicit some feedback before
>>> committing.
>>>
>>> Mike
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>

On 06/11/2010 02:38 PM, jas...@cr... wrote:
> On 6/11/10 1:02 PM, Michael Droettboom wrote:
>    
>>      
>>> It appears that the difficulty is that quantization is exposed at the
>>> python level only for collections, via iter_segments.
>>>
>>>
>>>        
>> Sort of.  Lines (but none of the other artists) follow what is set by
>> "set_snap" (the use of two terms for the same thing is also a problem,
>> of course).  This needs to be extended to other artists (and other
>> relevant backend methods other than draw_path, if necessary).  But I
>> think for convenience, it should also be a global rcParam.
>>      
> I think a work-around, then (at least it seems to work for me), is
> setting both snap to False and antialiased to False for the spines.
> That won't solve the issue for other horizontal lines, but at least it
> takes care of having the correct origin for the intersection of the
> spines.  (Correct me if I'm wrong, of course!)
>
> from matplotlib import pyplot as plt
> import numpy as np
> fig = plt.figure()
> ax = fig.add_subplot(1,1,1, aspect='equal')
> line1=ax.plot([-1,1],[0,0], color='blue')
> line2=ax.plot([-1,1],[-1,1], color='red',zorder=5)
> ax.set_xlim(-1.1,1.1)
> ax.set_ylim(-1.1,1.1)
> ax.spines['left'].set_position('zero')
> ax.spines['left'].set_snap(False)
> ax.spines['left'].set_antialiased(False)
> ax.spines['right'].set_color('none')
> ax.spines['bottom'].set_position('zero')
> ax.spines['bottom'].set_snap(False)
> ax.spines['bottom'].set_antialiased(False)
> ax.spines['top'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png',dpi=100)
>    
I've committed a patch that provides a global snap setting in r8415.  
Set the rcParam "path.snap" to False to turn off all snapping (though it 
should be equivalent to your "set_snap" calls above -- just possibly 
more convenient).

However, I think turning anti-aliasing off will give you the same 
problem at some scales, as anti-aliasing has basically the same effect 
as snapping: rounding to integral pixel values.  Try an odd dpi such as 
"67" for example.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 6/11/10 1:02 PM, Michael Droettboom wrote:
>
>> It appears that the difficulty is that quantization is exposed at the
>> python level only for collections, via iter_segments.
>>
>>      
> Sort of.  Lines (but none of the other artists) follow what is set by
> "set_snap" (the use of two terms for the same thing is also a problem,
> of course).  This needs to be extended to other artists (and other
> relevant backend methods other than draw_path, if necessary).  But I
> think for convenience, it should also be a global rcParam.

I think a work-around, then (at least it seems to work for me), is 
setting both snap to False and antialiased to False for the spines.  
That won't solve the issue for other horizontal lines, but at least it 
takes care of having the correct origin for the intersection of the 
spines.  (Correct me if I'm wrong, of course!)

from matplotlib import pyplot as plt
import numpy as np
fig = plt.figure()
ax = fig.add_subplot(1,1,1, aspect='equal')
line1=ax.plot([-1,1],[0,0], color='blue')
line2=ax.plot([-1,1],[-1,1], color='red',zorder=5)
ax.set_xlim(-1.1,1.1)
ax.set_ylim(-1.1,1.1)
ax.spines['left'].set_position('zero')
ax.spines['left'].set_snap(False)
ax.spines['left'].set_antialiased(False)
ax.spines['right'].set_color('none')
ax.spines['bottom'].set_position('zero')
ax.spines['bottom'].set_snap(False)
ax.spines['bottom'].set_antialiased(False)
ax.spines['top'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
fig.savefig('test.png',dpi=100)

Thanks,

Jason

Wx, Gtk, Tk all work for me.  Couldn't test Qt "classic" as I don't have 
pyqt 3.x installed on my system.

Mike

On 06/11/2010 01:56 PM, Eric Firing wrote:
> On 06/11/2010 07:44 AM, Michael Droettboom wrote:
>    
>> The Qt4 backend crashes with a Segmentation Fault when no toolbar is
>> requested. For example:
>>      
> Mike,
>
> Have the other backends been tested for the same problem?
>
> Eric
>
>    
>> from matplotlib import pyplot as plt
>> from matplotlib import rcParams
>> rcParams['toolbar'] = 'None'
>> fig=plt.figure()
>> plt.show()
>>
>> I have attached a possible patch, but since I've never really touched
>> the Qt4 backend before, thought I'd solicit some feedback before
>> committing.
>>
>> Mike
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>      
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 06/11/2010 01:54 PM, Eric Firing wrote:
> On 06/11/2010 07:39 AM, Michael Droettboom wrote:
>    
>> On 06/11/2010 01:31 PM, jas...@cr... wrote:
>>      
>>> On 6/11/10 9:44 AM, Michael Droettboom wrote:
>>>
>>>        
>>>> On 06/11/2010 09:46 AM, Michael Droettboom wrote:
>>>>
>>>>
>>>>          
>>>>> However, there's actually a bug in the quantizer that your example
>>>>> illustrates.  Since the spine lines in your example have a stroke width
>>>>> of 4 pixels, they should actually be rounded to the nearest pixel edge,
>>>>> not nearest center pixel.  So the quantizing is causing this slight
>>>>> alignment problem *and* making the straight lines look fuzzier than they
>>>>> should.  I'm planning on writing a patch that will take stroke width
>>>>> into account to address this.  By coincidence only, this will also make
>>>>> your example plot look more accurate (but that's dependent on the
>>>>> specific scale being used).
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> This specific bug is fixed in r8414.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>          
>>> I tested your fix, and now this example gives the same sort of problem
>>> (note that in this case, the spine is 1 pixel wide; I've just changed
>>> the dpi):
>>>
>>>        
>> That's exactly what I meant when I said "By coincidence only, this will
>> also make your example plot look more accurate (but that's dependent on
>> the specific scale being used)."  This isn't a proper fix, other than to
>> make even-width lines looking less fuzzy.  The correct fix (to either
>> make quanitizing an rcParam or to adjust the data based on it) is much
>> more work.
>>      
> I don't see how any reasonable algorithm could do such a data adjustment
> in general, so if the half-pixel inaccuracy is a problem, then I think
> using an rcParam to turn off quantizing is the way to go.
>    
Yeah -- as I considered it further, I'm coming to the same conclusion.  
We could optimize for a single point, eg. (0, 0), but not for all ticks, 
gridlines etc.
> It appears that the difficulty is that quantization is exposed at the
> python level only for collections, via iter_segments.
>    
Sort of.  Lines (but none of the other artists) follow what is set by 
"set_snap" (the use of two terms for the same thing is also a problem, 
of course).  This needs to be extended to other artists (and other 
relevant backend methods other than draw_path, if necessary).  But I 
think for convenience, it should also be a global rcParam.

Mike

> Eric
>
>
>    
>> Mike
>>
>>      
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA