matplotlib-devel Mailing List for matplotlib

On 02/29/2012 12:47 PM, S Krieger wrote:
> Hi,
>
> My name is Sammy, I'm a university student currently pursing a bachelors
> in computer science. I have been working with the pyplot API for some
> time. It has been a very useful tool for me, especially in some of my
> courses (so thank you for making it!).
>
> I'd really like to get involved with the open source community, and due
> to my interest and experience with pyplot, I've reflected on a number of
> ways that the documentation could be improved upon.
>
> I've taken a number of courses which really focus on the subject area
> and differing structures of documentation. Moreover, I've engaged in a
> number of projects working in both coding and documentation. As such I
> was just wondering if it would be of interest to the group if I were to
> write up some alternative documentation for even parts of the pyplot
> library? Alternatively, if there are any other areas in which I could be
> of assistance please let me know as well, and I'll be happy to help.
>
> Thanks for your time, and hope to hear from you!
>
> Sammy
>

Sammy,

We would welcome improved documentation, as well as your ideas on 
documentation strategy.  You can tell us about the latter on this list, 
and you can submit the former as github pull requests from your fork of mpl.

Eric

>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

That would be great!  There's always room for improvement in the docs.  
The best way you can help is to read up on how to generate github pull 
requests (in the matplotlib developer docs) and start submitting 
proposals for things that could be improved.

Cheers,
Mike

On 02/29/2012 05:47 PM, S Krieger wrote:
> Hi,
>
> My name is Sammy, I'm a university student currently pursing a 
> bachelors in computer science. I have been working with the pyplot API 
> for some time. It has been a very useful tool for me, especially in 
> some of my courses (so thank you for making it!).
>
> I'd really like to get involved with the open source community, and 
> due to my interest and experience with pyplot, I've reflected on a 
> number of ways that the documentation could be improved upon.
>
> I've taken a number of courses which really focus on the subject area 
> and differing structures of documentation. Moreover, I've engaged in a 
> number of projects working in both coding and documentation. As such I 
> was just wondering if it would be of interest to the group if I were 
> to write up some alternative documentation for even parts of the 
> pyplot library? Alternatively, if there are any other areas in which I 
> could be of assistance please let me know as well, and I'll be happy 
> to help.
>
> Thanks for your time, and hope to hear from you!
>
> Sammy
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

My name is Sammy, I'm a university student currently pursing a bachelors in
computer science. I have been working with the pyplot API for some time. It
has been a very useful tool for me, especially in some of my courses (so
thank you for making it!).

I'd really like to get involved with the open source community, and due to
my interest and experience with pyplot, I've reflected on a number of ways
that the documentation could be improved upon.

I've taken a number of courses which really focus on the subject area and
differing structures of documentation. Moreover, I've engaged in a number
of projects working in both coding and documentation. As such I was just
wondering if it would be of interest to the group if I were to write up
some alternative documentation for even parts of the pyplot library?
Alternatively, if there are any other areas in which I could be of
assistance please let me know as well, and I'll be happy to help.

Thanks for your time, and hope to hear from you!

Sammy

On Tue, Feb 28, 2012 at 1:00 PM, Tony Yu <ts...@gm...> wrote:

>
>
> On Tue, Feb 28, 2012 at 11:44 AM, Benjamin Root <ben...@ou...> wrote:
>
>> On Mon, Feb 27, 2012 at 9:45 PM, Tony Yu <ts...@gm...> wrote:
>>
>>>
>>>
>>> On Fri, Feb 17, 2012 at 12:17 PM, Benjamin Root <ben...@ou...> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Feb 17, 2012 at 11:06 AM, Ryan May <rm...@gm...> wrote:
>>>>
>>>>> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root <ben...@ou...>
>>>>> wrote:
>>>>> > Hello all,
>>>>> >
>>>>> > I tracked down an annoying problem in one of applications to the
>>>>> Lasso
>>>>> > widget I was using.  The widget constructor lets you specify a
>>>>> function to
>>>>> > call when the lasso operation is complete.  So, when I create a
>>>>> Lasso, I set
>>>>> > the canvas's widget lock to the new lasso, and the release function
>>>>> will
>>>>> > unlock it when it is done.  What would occassionally happen is that
>>>>> the
>>>>> > canvas wouldn't get unlocked and I wouldn't be able to use any other
>>>>> widget
>>>>> > tools.
>>>>> >
>>>>> > It turns out that the release function is not called if the number of
>>>>> > vertices collected is not more than 2.  So, accidental clicks that
>>>>> activate
>>>>> > the lasso never get cleaned up.  Because of this design, it would be
>>>>> > impossible to guarantee a proper cleanup.  One could add another
>>>>> > button_release callback to clean up if the canvas is still locked,
>>>>> but there
>>>>> > is no guarantee that that callback is not called before the lasso's
>>>>> > callback, thereby creating a race condition.
>>>>> >
>>>>> > The only solution I see is to guarantee that the release callback
>>>>> will be
>>>>> > called regardless of the length of the vertices array.  Does anybody
>>>>> see a
>>>>> > problem with that?
>>>>>
>>>>> Not having looked at the Lasso code, wouldn't it be possible to use
>>>>> one internal callback for the button_release event, and have this
>>>>> callback call the users' callbacks if points > 2 and always handle the
>>>>> unlocking of the canvas?
>>>>>
>>>>> Ryan
>>>>>
>>>>>
>>>> The problem is that the constructor does not establish the lock.  It is
>>>> the user's responsibility to establish a lock and release the locks for
>>>> these widgets.  Plus, if the user's callback has cleanup code (such as mine
>>>> did), not guaranteeing that the callback is done can leave behind a mess.
>>>>
>>>> Now, if we were to change the paradigm so that the Widget class
>>>> establishes and releases the lock, and that the user should never handle
>>>> that, then that might be a partial solution, but still leaves unsolved the
>>>> user's cleanup needs.
>>>>
>>>> Ben Root
>>>>
>>>> I just started looking at the Lasso widget for some other changes, and
>>> I agree: the `points > 2` check should be removed.
>>>
>>> As for the design of Lasso, I don't quite understand why it disconnects
>>> the callbacks after a single call. If the onpress event from the lasso
>>> demo<http://matplotlib.sourceforge.net/examples/event_handling/lasso_demo.html>was made a method of Lasso, then you could reuse the Lasso widget instead
>>> of having to create a new one for each selection. Of course, this might
>>> complicate the widget lock used in the demo, but that's true for all other
>>> widgets, right?
>>>
>>> -Tony
>>>
>>>
>> The Lasso disconnects itself after the button_release event because
>> that's what indicates that you are done.  The user gets back a single
>> Line2D object that is assumed to represent a single path with no breaks.
>> Reusing the Lasso widget would be a situation that would require a
>> different idiom for user interaction.  I wouldn't be against a "MultiLasso"
>> widget that works differently from Lasso, but I really wouldn't want to
>> make changes to existing user widgets.  It is iffy enough about whether to
>> remove the point-count-check.
>>
>> Ben Root
>>
>>
> Wouldn't this argument suggest that `RectangleSelector` and `SpanSelector`
> should disconnect as well? I think their functionalities and their
> behaviors are (or should be) pretty similar.
>

Hadn't thought about that, and I don't use them, so I hadn't noticed.


>
> In any case, I agree that changing this behavior of `Lasso` is not
> desirable for compatibility reasons. I'll write up something that looks
> more like `RectangleSelector` and `SpanSelector`. Maybe `LassoSelector`?
>

Actually, I like that idea.  It gives a consistent naming scheme.

Ben Root

On Tue, Feb 28, 2012 at 10:58 AM, John Hunter <jd...@gm...> wrote:

>
>
> On Tue, Feb 28, 2012 at 10:44 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>> The Lasso disconnects itself after the button_release event because
>> that's what indicates that you are done.  The user gets back a single
>> Line2D object that is assumed to represent a single path with no breaks.
>> Reusing the Lasso widget would be a situation that would require a
>> different idiom for user interaction.  I wouldn't be against a "MultiLasso"
>> widget that works differently from Lasso, but I really wouldn't want to
>> make changes to existing user widgets.  It is iffy enough about whether to
>> remove the point-count-check.
>>
>>
> I added the point count check according to git blame and I don't remember
> why but I agree is doesn't look like it makes sense to me.  I think this
> lasso is lightly used based on the volume of questions we get about it.
>  One reason it may be lightly used is because it is hard to work with.  If
> we can improve it, even changing functionality,  I would be in favor.  Eg,
> allowing the same Lasso to handle repeated selections makes sense to me.
>  If the change looks too onerous, we could call it Lasso2 and deprecate the
> former.
>

I think that logic is slightly faulty.  Another reason why we don't get a
lot of questions about it could be because it does (almost) exactly what
users want.  Currently, I use the Lasso widget in my track_maker project to
select storm cells in a movie of radar images.  Because I have multiple
modes to the program, a persistent Lasso object makes little sense. I also
want the Lasso's line to disappear after I am done selecting it so that I
can put in a polygon patch of my coloring and hatching.

I am skeptical of any redesign of Lasso.  I am willing to see what others
have in mind, but I still think that it might better belong in a new class
"MultiLasso".  I see no reason to deprecate the current Lasso (only to fix
it).

Cheers!
Ben Root

On Tue, Feb 28, 2012 at 10:44 AM, Benjamin Root <ben...@ou...> wrote:

>
> The Lasso disconnects itself after the button_release event because that's
> what indicates that you are done.  The user gets back a single Line2D
> object that is assumed to represent a single path with no breaks.  Reusing
> the Lasso widget would be a situation that would require a different idiom
> for user interaction.  I wouldn't be against a "MultiLasso" widget that
> works differently from Lasso, but I really wouldn't want to make changes to
> existing user widgets.  It is iffy enough about whether to remove the
> point-count-check.
>
>
I added the point count check according to git blame and I don't remember
why but I agree is doesn't look like it makes sense to me.  I think this
lasso is lightly used based on the volume of questions we get about it.
 One reason it may be lightly used is because it is hard to work with.  If
we can improve it, even changing functionality,  I would be in favor.  Eg,
allowing the same Lasso to handle repeated selections makes sense to me.
 If the change looks too onerous, we could call it Lasso2 and deprecate the
former.

On Mon, Feb 27, 2012 at 9:45 PM, Tony Yu <ts...@gm...> wrote:

>
>
> On Fri, Feb 17, 2012 at 12:17 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Fri, Feb 17, 2012 at 11:06 AM, Ryan May <rm...@gm...> wrote:
>>
>>> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root <ben...@ou...> wrote:
>>> > Hello all,
>>> >
>>> > I tracked down an annoying problem in one of applications to the Lasso
>>> > widget I was using.  The widget constructor lets you specify a
>>> function to
>>> > call when the lasso operation is complete.  So, when I create a Lasso,
>>> I set
>>> > the canvas's widget lock to the new lasso, and the release function
>>> will
>>> > unlock it when it is done.  What would occassionally happen is that the
>>> > canvas wouldn't get unlocked and I wouldn't be able to use any other
>>> widget
>>> > tools.
>>> >
>>> > It turns out that the release function is not called if the number of
>>> > vertices collected is not more than 2.  So, accidental clicks that
>>> activate
>>> > the lasso never get cleaned up.  Because of this design, it would be
>>> > impossible to guarantee a proper cleanup.  One could add another
>>> > button_release callback to clean up if the canvas is still locked, but
>>> there
>>> > is no guarantee that that callback is not called before the lasso's
>>> > callback, thereby creating a race condition.
>>> >
>>> > The only solution I see is to guarantee that the release callback will
>>> be
>>> > called regardless of the length of the vertices array.  Does anybody
>>> see a
>>> > problem with that?
>>>
>>> Not having looked at the Lasso code, wouldn't it be possible to use
>>> one internal callback for the button_release event, and have this
>>> callback call the users' callbacks if points > 2 and always handle the
>>> unlocking of the canvas?
>>>
>>> Ryan
>>>
>>>
>> The problem is that the constructor does not establish the lock.  It is
>> the user's responsibility to establish a lock and release the locks for
>> these widgets.  Plus, if the user's callback has cleanup code (such as mine
>> did), not guaranteeing that the callback is done can leave behind a mess.
>>
>> Now, if we were to change the paradigm so that the Widget class
>> establishes and releases the lock, and that the user should never handle
>> that, then that might be a partial solution, but still leaves unsolved the
>> user's cleanup needs.
>>
>> Ben Root
>>
>> I just started looking at the Lasso widget for some other changes, and I
> agree: the `points > 2` check should be removed.
>
> As for the design of Lasso, I don't quite understand why it disconnects
> the callbacks after a single call. If the onpress event from the lasso
> demo<http://matplotlib.sourceforge.net/examples/event_handling/lasso_demo.html>was made a method of Lasso, then you could reuse the Lasso widget instead
> of having to create a new one for each selection. Of course, this might
> complicate the widget lock used in the demo, but that's true for all other
> widgets, right?
>
> -Tony
>
>
The Lasso disconnects itself after the button_release event because that's
what indicates that you are done.  The user gets back a single Line2D
object that is assumed to represent a single path with no breaks.  Reusing
the Lasso widget would be a situation that would require a different idiom
for user interaction.  I wouldn't be against a "MultiLasso" widget that
works differently from Lasso, but I really wouldn't want to make changes to
existing user widgets.  It is iffy enough about whether to remove the
point-count-check.

Ben Root

On Fri, Feb 17, 2012 at 12:17 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Fri, Feb 17, 2012 at 11:06 AM, Ryan May <rm...@gm...> wrote:
>
>> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root <ben...@ou...> wrote:
>> > Hello all,
>> >
>> > I tracked down an annoying problem in one of applications to the Lasso
>> > widget I was using.  The widget constructor lets you specify a function
>> to
>> > call when the lasso operation is complete.  So, when I create a Lasso,
>> I set
>> > the canvas's widget lock to the new lasso, and the release function will
>> > unlock it when it is done.  What would occassionally happen is that the
>> > canvas wouldn't get unlocked and I wouldn't be able to use any other
>> widget
>> > tools.
>> >
>> > It turns out that the release function is not called if the number of
>> > vertices collected is not more than 2.  So, accidental clicks that
>> activate
>> > the lasso never get cleaned up.  Because of this design, it would be
>> > impossible to guarantee a proper cleanup.  One could add another
>> > button_release callback to clean up if the canvas is still locked, but
>> there
>> > is no guarantee that that callback is not called before the lasso's
>> > callback, thereby creating a race condition.
>> >
>> > The only solution I see is to guarantee that the release callback will
>> be
>> > called regardless of the length of the vertices array.  Does anybody
>> see a
>> > problem with that?
>>
>> Not having looked at the Lasso code, wouldn't it be possible to use
>> one internal callback for the button_release event, and have this
>> callback call the users' callbacks if points > 2 and always handle the
>> unlocking of the canvas?
>>
>> Ryan
>>
>>
> The problem is that the constructor does not establish the lock.  It is
> the user's responsibility to establish a lock and release the locks for
> these widgets.  Plus, if the user's callback has cleanup code (such as mine
> did), not guaranteeing that the callback is done can leave behind a mess.
>
> Now, if we were to change the paradigm so that the Widget class
> establishes and releases the lock, and that the user should never handle
> that, then that might be a partial solution, but still leaves unsolved the
> user's cleanup needs.
>
> Ben Root
>
> I just started looking at the Lasso widget for some other changes, and I
agree: the `points > 2` check should be removed.

As for the design of Lasso, I don't quite understand why it disconnects the
callbacks after a single call. If the onpress event from the lasso
demo<http://matplotlib.sourceforge.net/examples/event_handling/lasso_demo.html>was
made a method of Lasso, then you could reuse the Lasso widget instead
of having to create a new one for each selection. Of course, this might
complicate the widget lock used in the demo, but that's true for all other
widgets, right?

-Tony

On Sun, Feb 26, 2012 at 6:16 PM, Mark Lawrence <bre...@ya...>wrote:

> On 25/02/2012 17:13, John Hunter wrote:
>
> > After we get the bugfix out I'd like to gear up for a major python3
> release.
>
> Huge +1.
>
> I understand that the majority of Python and hence matplotlib people
> work on *nix boxes, so if you'd like a hand with testing, or anything
> else come to think of it, on my Windows Vista box feel free to ask, as
> I've been using matplotlib for around seven years and don't mind trying
> to put a bit back in.
>
>
That would be great-- you can cut your teeth testing the release candidates
for the bugfix release in the current cycle, familiarize yourself with how
to run the tests, etc.

We definitely have a shortage of OSX and windows testing, especially the
latter, because few people run from git HEAD  on windows, but lots of
people do on linux.

Just chime in when you see the announcements for "rc" release candidates on
the users or devel lists.

Thanks!
JDH

On 25/02/2012 17:13, John Hunter wrote:

> After we get the bugfix out I'd like to gear up for a major python3 release.

Huge +1.

I understand that the majority of Python and hence matplotlib people 
work on *nix boxes, so if you'd like a hand with testing, or anything 
else come to think of it, on my Windows Vista box feel free to ask, as 
I've been using matplotlib for around seven years and don't mind trying 
to put a bit back in.

-- 
Cheers.

Mark Lawrence.

On Sun, Feb 26, 2012 at 9:26 AM, Pierre Raybaut <pie...@gm...>wrote:

> I found out that a similar issue was reported for Spyder the same day
> as this one...
>
> So I just posted something about this bug on PyQt mailing list:
> http://www.riverbankcomputing.com/pipermail/pyqt/2012-February/031166.html
>
>

I added your fix in pull request
https://github.com/matplotlib/matplotlib/pull/716 so it should come out in
the bug fix release we are preparing.


Also, something you might be interested in for your qt apps: I exposed the
default mpl key handling to embedded applications

https://github.com/matplotlib/matplotlib/pull/717

Thanks a bunch for the suggested fix -- this was a vexing issue and
particularly bad for the animation examples which caused all of my demos to
explode is a sea of C++ warnings when I closed the window.
JDH

I found out that a similar issue was reported for Spyder the same day
as this one...

So I just posted something about this bug on PyQt mailing list:
http://www.riverbankcomputing.com/pipermail/pyqt/2012-February/031166.html

-Pierre

Le 26 février 2012 12:23, Pierre Raybaut <pie...@gm...> a écrit :
> Le 25/02/2012 22:59, John Hunter a écrit :
>
>
>
> On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root <ben...@ou...> wrote:
>>>
>>>
>>> >     I would be interested in accelerating the schedule.  Since this is
>>> > a
>>> >     bug-fix release and not a major release, we can presume the tree is
>>> >     pretty stable.  How about we aim for an release candidate rc1 the
>>> >     week after next?  Are there any issues or pull requests that should
>>> >     hold the release?  If so, let's tag them with release-critical.
>>> >
>>> >     After we get the bugfix out I'd like to gear up for a major python3
>>> >     release.
>>> >
>>> >
>>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>>> > into them and there is no obvious reason to me why they aren't working.
>>>
>>> Are you referring to  771, 707, and 525?  771 would appear to be the
>>> most urgent.
>>
>>
>> 711 and 707.  Didn't even notice 525, but it is probably related to 707.
>>  If true, then 707 and 525 are likely focus issues (maybe window-manager
>> dependent?).  711 definitely seem to be release blocking.
>>
>
>
> Hi Pierre, we are still having trouble with the close event in mpl figure
> windows not being emitted.  I see you posted on this subject in 2009 and did
> some monkey patching to work around the problem for spyder
>
> http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html
>
> This was a while ago so I don't know if your suggestions are still
> appropriate for recent pyqt and mpl.  Would you have a minute to take a look
> at this mpl issue
>
> https://github.com/matplotlib/matplotlib/issues/711
>
> and advise us on a fix?
>
> Thanks,
> JDH
>
>
>
>
> Hi John,
>
> Replacing this (backend_qt4.py, class "FigureCanvasQT", line 141):
>         QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
>                                self.close_event)
> by this:
>         QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
>                                lambda: self.close_event())
> will solve this issue.
>
> The reason is that PyQt fails (silently) to call a method of this object
> just before detroying it. Using a lambda function will work, exactly the
> same as using a function (which is not bound to the object to be destroyed).
>
> Side note: I'm not sure that it's the intended behavior for PyQt...
>
> HTH,
> Pierre

Hi,

I will be on vacation with limited email from February 18-25, 2012.

Bonjour,

Je serai en conge du 18 au 25 fevrier, 2012.

Thanks,
David

 Le 25/02/2012 22:59, John Hunter a écrit :



On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root <ben...@ou...> wrote:

>
>> >     I would be interested in accelerating the schedule.  Since this is a
>> >     bug-fix release and not a major release, we can presume the tree is
>> >     pretty stable.  How about we aim for an release candidate rc1 the
>> >     week after next?  Are there any issues or pull requests that should
>> >     hold the release?  If so, let's tag them with release-critical.
>> >
>> >     After we get the bugfix out I'd like to gear up for a major python3
>> >     release.
>> >
>> >
>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>> > into them and there is no obvious reason to me why they aren't working.
>>
>> Are you referring to  771, 707, and 525?  771 would appear to be the
>> most urgent.
>
>
>   711 and 707.  Didn't even notice 525, but it is probably related to
> 707.  If true, then 707 and 525 are likely focus issues (maybe
> window-manager dependent?).  711 definitely seem to be release blocking.
>
>

 Hi Pierre, we are still having trouble with the close event in mpl figure
windows not being emitted.  I see you posted on this subject in 2009 and
did some monkey patching to work around the problem for spyder


http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html

This was a while ago so I don't know if your suggestions are still
appropriate for recent pyqt and mpl.  Would you have a minute to take a
look at this mpl issue

 https://github.com/matplotlib/matplotlib/issues/711

 and advise us on a fix?

 Thanks,
JDH




Hi John,

Replacing this (backend_qt4.py, class "FigureCanvasQT", line 141):
        QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
                               self.close_event)
by this:
        QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
                               lambda: self.close_event())
will solve this issue.

The reason is that PyQt fails (silently) to call a method of this object
just before detroying it. Using a lambda function will work, exactly the
same as using a function (which is not bound to the object to be destroyed).

Side note: I'm not sure that it's the intended behavior for PyQt...

HTH,
Pierre

On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root <ben...@ou...> wrote:

>
>> >     I would be interested in accelerating the schedule.  Since this is a
>> >     bug-fix release and not a major release, we can presume the tree is
>> >     pretty stable.  How about we aim for an release candidate rc1 the
>> >     week after next?  Are there any issues or pull requests that should
>> >     hold the release?  If so, let's tag them with release-critical.
>> >
>> >     After we get the bugfix out I'd like to gear up for a major python3
>> >     release.
>> >
>> >
>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>> > into them and there is no obvious reason to me why they aren't working.
>>
>> Are you referring to  771, 707, and 525?  771 would appear to be the
>> most urgent.
>
>
> 711 and 707.  Didn't even notice 525, but it is probably related to 707.
>  If true, then 707 and 525 are likely focus issues (maybe window-manager
> dependent?).  711 definitely seem to be release blocking.
>
>

Hi Pierre, we are still having trouble with the close event in mpl figure
windows not being emitted.  I see you posted on this subject in 2009 and
did some monkey patching to work around the problem for spyder

http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html

This was a while ago so I don't know if your suggestions are still
appropriate for recent pyqt and mpl.  Would you have a minute to take a
look at this mpl issue

https://github.com/matplotlib/matplotlib/issues/711

and advise us on a fix?

Thanks,
JDH

On Saturday, February 25, 2012, Eric Firing wrote:

> On 02/25/2012 08:34 AM, Benjamin Root wrote:
> >
> >
> > On Saturday, February 25, 2012, John Hunter wrote:
> >
> >
> >
> >     On Sat, Feb 25, 2012 at 8:34 AM, Benjamin Root <ben...@ou...<javascript:;>
> >     <javascript:_e({}, 'cvml', 'ben...@ou... <javascript:;>');>>
> wrote:
> >
> >
> >
> >         On Thursday, February 23, 2012, RuiDC wrote:
> >
> >
> >             Hi,
> >             There's a number of bugs fixed that would be nice to have
> >             without running
> >             git versions.
> >             Is there a release schedule for the next version?
> >
> >
> >         There is not one in place right now.  In about a month, I will
> >         be starting up my new job, which I hope will allow me to devote
> >         more time and effort to this project.  There are a number of
> >         features I have in mind to get added and there are many pull
> >         requests that needs evaluating.
> >
> >         Even if you are not a developer, members of this community can
> >         still help us out by trying out pull requests and letting us
> >         know if it works for them.
> >
> >
> >
> >     I would be interested in accelerating the schedule.  Since this is a
> >     bug-fix release and not a major release, we can presume the tree is
> >     pretty stable.  How about we aim for an release candidate rc1 the
> >     week after next?  Are there any issues or pull requests that should
> >     hold the release?  If so, let's tag them with release-critical.
> >
> >     After we get the bugfix out I'd like to gear up for a major python3
> >     release.
> >
> >
> > The QT4 event handling bugs needs a qt expert on them. I tried looking
> > into them and there is no obvious reason to me why they aren't working.
>
> Are you referring to  771, 707, and 525?  771 would appear to be the
> most urgent.


711 and 707.  Didn't even notice 525, but it is probably related to 707.
 If true, then 707 and 525 are likely focus issues (maybe window-manager
dependent?).  711 definitely seem to be release blocking.

Ben Root

On 02/25/2012 08:34 AM, Benjamin Root wrote:
>
>
> On Saturday, February 25, 2012, John Hunter wrote:
>
>
>
>     On Sat, Feb 25, 2012 at 8:34 AM, Benjamin Root <ben...@ou...
>     <javascript:_e({}, 'cvml', 'ben...@ou...');>> wrote:
>
>
>
>         On Thursday, February 23, 2012, RuiDC wrote:
>
>
>             Hi,
>             There's a number of bugs fixed that would be nice to have
>             without running
>             git versions.
>             Is there a release schedule for the next version?
>
>
>         There is not one in place right now.  In about a month, I will
>         be starting up my new job, which I hope will allow me to devote
>         more time and effort to this project.  There are a number of
>         features I have in mind to get added and there are many pull
>         requests that needs evaluating.
>
>         Even if you are not a developer, members of this community can
>         still help us out by trying out pull requests and letting us
>         know if it works for them.
>
>
>
>     I would be interested in accelerating the schedule.  Since this is a
>     bug-fix release and not a major release, we can presume the tree is
>     pretty stable.  How about we aim for an release candidate rc1 the
>     week after next?  Are there any issues or pull requests that should
>     hold the release?  If so, let's tag them with release-critical.
>
>     After we get the bugfix out I'd like to gear up for a major python3
>     release.
>
>
> The QT4 event handling bugs needs a qt expert on them. I tried looking
> into them and there is no obvious reason to me why they aren't working.

Are you referring to  771, 707, and 525?  771 would appear to be the 
most urgent.

>
> I would be amendable to a bug-fix release soon to hold everybody over
> for the next major release.

Agreed.

Eric

>
> Ben Root
>

Hi,

I will be on vacation with limited email from February 18-25, 2012.

Bonjour,

Je serai en conge du 18 au 25 fevrier, 2012.

Thanks,
David

On Saturday, February 25, 2012, John Hunter wrote:

>
>
> On Sat, Feb 25, 2012 at 8:34 AM, Benjamin Root <ben...@ou...<javascript:_e({}, 'cvml', 'ben...@ou...');>
> > wrote:
>
>>
>>
>> On Thursday, February 23, 2012, RuiDC wrote:
>>
>>>
>>> Hi,
>>> There's a number of bugs fixed that would be nice to have without running
>>> git versions.
>>> Is there a release schedule for the next version?
>>
>>
>> There is not one in place right now.  In about a month, I will be
>> starting up my new job, which I hope will allow me to devote more time and
>> effort to this project.  There are a number of features I have in mind to
>> get added and there are many pull requests that needs evaluating.
>>
>> Even if you are not a developer, members of this community can still help
>> us out by trying out pull requests and letting us know if it works for them.
>>
>
>
> I would be interested in accelerating the schedule.  Since this is a
> bug-fix release and not a major release, we can presume the tree is pretty
> stable.  How about we aim for an release candidate rc1 the week after next?
>  Are there any issues or pull requests that should hold the release?  If
> so, let's tag them with release-critical.
>
> After we get the bugfix out I'd like to gear up for a major python3
> release.
>

The QT4 event handling bugs needs a qt expert on them. I tried looking into
them and there is no obvious reason to me why they aren't working.

I would be amendable to a bug-fix release soon to hold everybody over for
the next major release.

Ben Root

On Sat, Feb 25, 2012 at 8:34 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Thursday, February 23, 2012, RuiDC wrote:
>
>>
>> Hi,
>> There's a number of bugs fixed that would be nice to have without running
>> git versions.
>> Is there a release schedule for the next version?
>
>
> There is not one in place right now.  In about a month, I will be starting
> up my new job, which I hope will allow me to devote more time and effort to
> this project.  There are a number of features I have in mind to get added
> and there are many pull requests that needs evaluating.
>
> Even if you are not a developer, members of this community can still help
> us out by trying out pull requests and letting us know if it works for them.
>


I would be interested in accelerating the schedule.  Since this is a
bug-fix release and not a major release, we can presume the tree is pretty
stable.  How about we aim for an release candidate rc1 the week after next?
 Are there any issues or pull requests that should hold the release?  If
so, let's tag them with release-critical.

After we get the bugfix out I'd like to gear up for a major python3 release.

On Thursday, February 23, 2012, RuiDC wrote:

>
> Hi,
> There's a number of bugs fixed that would be nice to have without running
> git versions.
> Is there a release schedule for the next version?


There is not one in place right now.  In about a month, I will be starting
up my new job, which I hope will allow me to devote more time and effort to
this project.  There are a number of features I have in mind to get added
and there are many pull requests that needs evaluating.

Even if you are not a developer, members of this community can still help
us out by trying out pull requests and letting us know if it works for them.

Cheers!
Ben Root

Hi,
There's a number of bugs fixed that would be nice to have without running
git versions. 
Is there a release schedule for the next version?
-- 
View this message in context: http://old.nabble.com/release-schedule-for-next-version-tp33378272p33378272.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Thursday, February 16, 2012, Pavel Margolin wrote:

>  Is this possible? How difficult is it? ****
>
> Is anyone interested in consulting work porting Matplotlib to IronPython?*
> ***
>
> ** **
>
> Appreciate any help/suggestions.****
>
> ** **
>
> Thanks****
>
>
I do not work with IronPython, but I would imagine that you need numpy for
IronPython first.  MS paid for some refactoring work a few years ago for
Numpy, but I don't know the status or completeness of that work.

Numpy is so essential to the internals of mpl that you would need to have
that done first before anything else.
-
Ben Root

Hi,

I will be on vacation with limited email from February 18-25, 2012.

Bonjour,

Je serai en conge du 18 au 25 fevrier, 2012.

Thanks,
David

Hi,

I will be on vacation with limited email from February 18-25, 2012.

Bonjour,

Je serai en conge du 18 au 25 fevrier, 2012.

Thanks,
David