matplotlib-devel Mailing List for matplotlib

Hi Derek,

Can you perhaps ask the Fink developers to provide a framework installation of Python? Most matplotlib users who ran into framework-related bugs were Fink users.

Best,
-Michiel.

--- On Mon, 4/15/13, Derek Homeier <de...@as...> wrote:

> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, April 15, 2013, 11:00 AM
> Hi Michiel,
> 
> On 15.04.2013, at 6:03AM, Michiel de Hoon <mjl...@ya...>
> wrote:
> 
> > --- On Sun, 4/14/13, Derek Homeier <de...@as...>
> wrote:
> >> Of course if there are any other possible negative
> effects
> >> besides the window handling, I'd take your point.
> > 
> > Several bugs have been reported in the past that turned
> out to be due to Python not being installed as a framework.
> For example, the file selection window when saving a figure
> doesn't respond. This has been a major hassle, since each of
> those bug reports take time to investigate before realizing
> that it is due to the Python installation.
> 
> OK, that is a valid reason! I vaguely remember some problems
> with that in the past,
> though haven't experienced any of that in a long time (just
> tested 'Save File', and I've
> been regularly using 'Configure Subplots'). But this is
> probably a case where a
> Warning might not keep all users from filing a bug. :-(
> The QT4Agg backend has its ups as well, though there still
> seem to be some quirks,
> too (e.g. the zoom rectangle only shows up with the left and
> lower border); I will probably
> become a fan of the line configuration tool that allows you
> to switch back to linear from a
> log axis scale (in the command line there seems to be no
> return from plt.semilogy() or
> plt.loglog())!
> 
> Cheers,
>            
>            
> Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi Mike, Ryan,

Thanks for your comments. I have made a pull request; see:
https://github.com/matplotlib/matplotlib/pull/1907

Best,
-Michiel

--- On Mon, 4/15/13, Michael Droettboom <md...@st...> wrote:

> From: Michael Droettboom <md...@st...>
> Subject: Re: [matplotlib-devel] Timers independent of canvases
> To: mat...@li...
> Date: Monday, April 15, 2013, 10:56 AM
> Thanks for doing this.  This
> looks like quite an improvement!
> 
> Why don't you go ahead and make a pull request.  I
> think on the whole 
> the idea is sound, I just have a few minor comments that can
> probably be 
> dealt with more efficiently in a PR.
> 
> Mike
> 
> On 04/12/2013 10:32 PM, Michiel de Hoon wrote:
> > Dear all,
> >
> > The animation code in matplotlib relies on timers to
> update the animated figures. Currently a new timer is
> created by calling new_timer on a canvas, as in
> >
> >>>> f = pylab.figure()
> >>>> timer = f.canvas.new_timer()
> > This seems a bit of a wrinkle. For example, you may
> want to associate a timer with multiple figures, or with no
> figure at all; also you may want to continue using a timer
> after a particular figure is closed.
> >
> > I would therefore propose to make timers independent of
> canvases. Something like this:
> >
> >>>> from matplotlib import events
> >>>> timer = events.Timer()
> > This has the additional advantage of making the
> different backends more similar to each other; in the
> current implementation some backends rely on the canvas when
> making a timer, while others ignore it.
> >
> > I have made a branch on github that does exactly this;
> see
> > https://github.com/mdehoon/matplotlib/tree/Timer
> > I have verified that the animation examples still work
> correctly with all backends.
> >
> > Any comments/suggestions/criticisms? If this seems a
> good idea, I can make a pull request.
> >
> > Best,
> > -Michiel.
> >
> >
> ------------------------------------------------------------------------------
> > Precog is a next-generation analytics platform capable
> of advanced
> > analytics on semi-structured data. The platform
> includes APIs for building
> > apps and a phenomenal toolset for data science.
> Developers can use
> > our toolset for easy data analysis & visualization.
> Get a free account!
> > http://www2.precog.com/precogplatform/slashdotnewsletter
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi Michiel,

On 15.04.2013, at 6:03AM, Michiel de Hoon <mjl...@ya...> wrote:

> --- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
>> Of course if there are any other possible negative effects
>> besides the window handling, I'd take your point.
> 
> Several bugs have been reported in the past that turned out to be due to Python not being installed as a framework. For example, the file selection window when saving a figure doesn't respond. This has been a major hassle, since each of those bug reports take time to investigate before realizing that it is due to the Python installation.

OK, that is a valid reason! I vaguely remember some problems with that in the past,
though haven't experienced any of that in a long time (just tested 'Save File', and I've
been regularly using 'Configure Subplots'). But this is probably a case where a
Warning might not keep all users from filing a bug. :-(
The QT4Agg backend has its ups as well, though there still seem to be some quirks,
too (e.g. the zoom rectangle only shows up with the left and lower border); I will probably
become a fan of the line configuration tool that allows you to switch back to linear from a
log axis scale (in the command line there seems to be no return from plt.semilogy() or
plt.loglog())!

Cheers,
						Derek

Thanks for doing this.  This looks like quite an improvement!

Why don't you go ahead and make a pull request.  I think on the whole 
the idea is sound, I just have a few minor comments that can probably be 
dealt with more efficiently in a PR.

Mike

On 04/12/2013 10:32 PM, Michiel de Hoon wrote:
> Dear all,
>
> The animation code in matplotlib relies on timers to update the animated figures. Currently a new timer is created by calling new_timer on a canvas, as in
>
>>>> f = pylab.figure()
>>>> timer = f.canvas.new_timer()
> This seems a bit of a wrinkle. For example, you may want to associate a timer with multiple figures, or with no figure at all; also you may want to continue using a timer after a particular figure is closed.
>
> I would therefore propose to make timers independent of canvases. Something like this:
>
>>>> from matplotlib import events
>>>> timer = events.Timer()
> This has the additional advantage of making the different backends more similar to each other; in the current implementation some backends rely on the canvas when making a timer, while others ignore it.
>
> I have made a branch on github that does exactly this; see
> https://github.com/mdehoon/matplotlib/tree/Timer
> I have verified that the animation examples still work correctly with all backends.
>
> Any comments/suggestions/criticisms? If this seems a good idea, I can make a pull request.
>
> Best,
> -Michiel.
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

No opposition here. The "rationale" behind the original location was:

1) Easy way to make it properly dependent on the backend
2) Easy way to get a handle on a widget when necessary (for Tk and Wx IIRC)

However, these were reasons of ease of implementation (aka. laziness) on my
part, no real technical reasons that I recall (clearly, since your branch
works).

So, +1.

Ryan


On Fri, Apr 12, 2013 at 9:32 PM, Michiel de Hoon <mjl...@ya...>wrote:

> Dear all,
>
> The animation code in matplotlib relies on timers to update the animated
> figures. Currently a new timer is created by calling new_timer on a canvas,
> as in
>
> >>> f = pylab.figure()
> >>> timer = f.canvas.new_timer()
>
> This seems a bit of a wrinkle. For example, you may want to associate a
> timer with multiple figures, or with no figure at all; also you may want to
> continue using a timer after a particular figure is closed.
>
> I would therefore propose to make timers independent of canvases.
> Something like this:
>
> >>> from matplotlib import events
> >>> timer = events.Timer()
>
> This has the additional advantage of making the different backends more
> similar to each other; in the current implementation some backends rely on
> the canvas when making a timer, while others ignore it.
>
> I have made a branch on github that does exactly this; see
> https://github.com/mdehoon/matplotlib/tree/Timer
> I have verified that the animation examples still work correctly with all
> backends.
>
> Any comments/suggestions/criticisms? If this seems a good idea, I can make
> a pull request.
>
> Best,
> -Michiel.
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi Derek,

--- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
> Of course if there are any other possible negative effects
> besides the window handling, I'd take your point.

Several bugs have been reported in the past that turned out to be due to Python not being installed as a framework. For example, the file selection window when saving a figure doesn't respond. This has been a major hassle, since each of those bug reports take time to investigate before realizing that it is due to the Python installation.

Best,
-Michiel.

Hi Michiel,

> This RuntimeError is there for a reason: If your Python is not installed as  a framework, the backend will not work correctly (and if you ignore the RuntimeError, you won't know if any problems you encounter are real bugs, or simply due to your Python not being installed as a framework).

I have used the MacOSX backend ever since I started working with Python,
and there only was a warning for the last 3 years or so. Other than my plot
windows evading the control of Exposé/Application switcher I have never
noticed any problems with this. Thus my request in my initial post to leave it
as a mere warning, since I'd think people can switch on their own decision
if they do not like the interaction (or lack thereof) with the window manager.
Otherwise I would have to grudgingly switch to another backend (seems now
that I could live with QT4Agg-Quartz or the like though), since installation as
as framework is not an option with Fink.
Of course if there are any other possible negative effects besides the window
handling, I'd take your point.

Best,
						Derek

Hi Derek,

--- On Sun, 4/14/13, Derek Homeier <de...@as...> wrote:
> The RuntimeError was enforced by the #ifdef
> WITH_NEXT_FRAMEWORK check that
> does not allow to use the backend at all, so I had to change
> this to a RuntimeWarning
> to be able to test the backend in the 1.3 branch.

This RuntimeError is there for a reason: If your Python is not installed as  a framework, the backend will not work correctly (and if you ignore the RuntimeError, you won't know if any problems you encounter are real bugs, or simply due to your Python not being installed as a framework).

Best,
-Michiel