patch for adding manual label location selection to clabel

Development matplotlib-devel
1

Hi,

Attached is a patch (created by issuing svn diff from the
matplotlib/trunk/matplotlib directory) for adding the capability to
manually select the location of contour labels in clabel. Though the
existing algorithm for automatically placing contour labels is very
good, for complex figures with multiple elements it is often desirable
to manually place labels. This functionality is meant to imitate the
matlab functionality of clabel(cs,'manual').

The attached patch includes a modified version of the changes I
previously made to add a "waitforbuttonpress" command to matplotlib as
these changes are a prerequisite for using the added functionality of
clabel (i.e., you shouldn't apply both patches, just this last one).

The changes work as follows:

cs = contour(x,y,z)
cl = clabel(cs,'manual')

(use the third mouse button to finish placing labels, second button to
erase a previously added label)

The patch isn't done - manually selected labels won't be rotated or
inline. There is also a need for general cleaning up and documentation.
I just want to see what people think about the approach before investing
more time. I added this functionality by adding a class
ContourLabelerWithManual that inherits from ContourLabeler and
BlockingMouseInput (the class used by ginput to interactively select
points). ContourSet then inherits from ContourLabelerWithManual instead
of ContourLabeler. If manual is selected, then it enters interactive
mode, if not, then results should be as before.

I also had to move the classes Blocking*Input from figure.py to a
separate file blocking_input.py to avoid circular imports.

Please let me know what you think. Also, I am wondering if the powers
that be would be willing to give me commit access to my own branch of
the matplotlib svn. I don't want to modify the trunk, but for my own
sanity, it would be nice to be able to keep track of my changes
somewhere. If not, I would like to here what other non-commit
developers do to best organize changes.

Thanks,
David

waitforbuttonpress_and_clabel.patch (17.8 KB)

···

--
**********************************
David M. Kaplan
Assistant Researcher
UCSC / Institute of Marine Sciences
Ocean Sciences
1156 High St.
SC, CA 95064

Phone: 831-459-4789
Fax: 831-459-4882
http://pmc.ucsc.edu/~dmk/
**********************************

2

The patch isn't done - manually selected labels won't be rotated or
inline. There is also a need for general cleaning up and documentation.
I just want to see what people think about the approach before investing
more time. I added this functionality by adding a class
ContourLabelerWithManual that inherits from ContourLabeler and
BlockingMouseInput (the class used by ginput to interactively select
points). ContourSet then inherits from ContourLabelerWithManual instead
of ContourLabeler. If manual is selected, then it enters interactive
mode, if not, then results should be as before.

Hi David,

I think this looks good. I would like to see it finished before
inclusion (eg rotating the labels inline) but this functionality looks
very useful. In general, I think it would be nice to have better
support for easy interaction with figures, eg for annotations. My
main question is whether blocking input is the best choice.
Admitedly, most users find it more intuitive to set up blocking input
rather than using non-blocking input that is terminated by a custom
button press, key stroke, or command, but I am worried about how
robust this is across user interfaces and environments, with all the
attendant problems of GUI threads, mainloops, etc. Gael has done a
nice job with ginput across backends, but this code is relatively new
and lightly tested. Basically, someone (probably you and Gael) will
need to be up to the task of supporting blocking input across user
interfaces, which probably isn't trivial but maybe I'm overly
cautious. Anyway, something to think about.

I also had to move the classes Blocking*Input from figure.py to a
separate file blocking_input.py to avoid circular imports.

A minor nit here: when you import blocking_input, you should use

  import matplotlib.blocking_input as blocking_input

rather than simply

  import blocking_input

as discussed in the coding guide:
http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html

On the subject of the docs, we are in the midst of a push to get beter
documentation for mpl, so anything you can add while working in terms
of tutorial or faq or whatever on the new code would be welcome. The
docs are in the doc subdir of the svn trunk.

Please let me know what you think. Also, I am wondering if the powers
that be would be willing to give me commit access to my own branch of
the matplotlib svn. I don't want to modify the trunk, but for my own
sanity, it would be nice to be able to keep track of my changes
somewhere. If not, I would like to here what other non-commit
developers do to best organize changes.

If you send me your sf id, I will add you to the developer list. I
don't mind you committing to the trunk unless you are afraid your
changes will break code. I am not a huge fan of having a lot of
branches.

Thanks for the submission -- I await more informed commentary from
those who actually use contouring....

JDH

···

On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dmk@...621...> wrote:

3

John Hunter wrote:

  

Please let me know what you think. Also, I am wondering if the powers
that be would be willing to give me commit access to my own branch of
the matplotlib svn. I don't want to modify the trunk, but for my own
sanity, it would be nice to be able to keep track of my changes
somewhere. If not, I would like to here what other non-commit
developers do to best organize changes.
    
If you send me your sf id, I will add you to the developer list. I
don't mind you committing to the trunk unless you are afraid your
changes will break code. I am not a huge fan of having a lot of
branches.
  

I agree with John -- you should just get developer access and be careful not to break things (easier said than done, especially for yours truly).

For future reference, though, I've been using git-svn (which lets you use git for a local repository that tracks a remote SVN repository) on a hobby-time project and have found it pretty useful for keeping my own local history without disturbing (or even having write access to) the central SVN repository. Of course, moving from svn to git requires retraining the fingers a little bit, but it's not too bad.

Cheers,
Mike

···

On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dmk@...621...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

4

John Hunter wrote:

The patch isn't done - manually selected labels won't be rotated or
inline. There is also a need for general cleaning up and documentation.
I just want to see what people think about the approach before investing
more time. I added this functionality by adding a class
ContourLabelerWithManual that inherits from ContourLabeler and
BlockingMouseInput (the class used by ginput to interactively select
points). ContourSet then inherits from ContourLabelerWithManual instead
of ContourLabeler. If manual is selected, then it enters interactive
mode, if not, then results should be as before.

Hi David,

I think this looks good. I would like to see it finished before
inclusion (eg rotating the labels inline) but this functionality looks
very useful. In general, I think it would be nice to have better
support for easy interaction with figures, eg for annotations. My
main question is whether blocking input is the best choice.
Admitedly, most users find it more intuitive to set up blocking input
rather than using non-blocking input that is terminated by a custom
button press, key stroke, or command, but I am worried about how
robust this is across user interfaces and environments, with all the
attendant problems of GUI threads, mainloops, etc. Gael has done a
nice job with ginput across backends, but this code is relatively new
and lightly tested. Basically, someone (probably you and Gael) will
need to be up to the task of supporting blocking input across user
interfaces, which probably isn't trivial but maybe I'm overly
cautious. Anyway, something to think about.

I also had to move the classes Blocking*Input from figure.py to a
separate file blocking_input.py to avoid circular imports.

A minor nit here: when you import blocking_input, you should use

  import matplotlib.blocking_input as blocking_input

rather than simply

  import blocking_input

as discussed in the coding guide:
http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html

On the subject of the docs, we are in the midst of a push to get beter
documentation for mpl, so anything you can add while working in terms
of tutorial or faq or whatever on the new code would be welcome. The
docs are in the doc subdir of the svn trunk.

Please let me know what you think. Also, I am wondering if the powers
that be would be willing to give me commit access to my own branch of
the matplotlib svn. I don't want to modify the trunk, but for my own
sanity, it would be nice to be able to keep track of my changes
somewhere. If not, I would like to here what other non-commit
developers do to best organize changes.

If you send me your sf id, I will add you to the developer list. I
don't mind you committing to the trunk unless you are afraid your
changes will break code. I am not a huge fan of having a lot of
branches.

Thanks for the submission -- I await more informed commentary from
those who actually use contouring....

I agree with adding the functionality provided it can be done in a robust and maintainable way; I have never looked into the arcane aspects of gui interaction across backends.

Unless it got fixed as part of the transforms re-write, there are problems even with the existing contour labeling, in that it does not (or did not) handle resizes well. Among the many things I have thought of but not gotten to is the idea that there should be a LabeledLine class to handle this outside of contour.py. The idea is that in addition to the ordinary line path, it would include a list of labels and positions (not sure what the right way to specify the positions is), and the class would handle breaking the path and inserting the correctly rotated text.

Eric

···

On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dmk@...621...> wrote:

JDH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

5

John Hunter wrote:

Thanks for the submission -- I await more informed commentary from
those who actually use contouring....

Just because the discussion about clabel started, I want to post a short snipplet of code that I found useful. It was some sort of hack to get a nicer float formating for contours: contour lines represented confidence levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly as I have written it here now. So, fmt='%.1f\%%' would have resulted in 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ...

So this was my solution:

# some kind of hack: a nicer floating point formating
class nf(float):
     def __repr__(self):
         str = '%.1f' % (self.__float__(),)
         if str[-1]=='0':
             return '%.0f' % self.__float__()
         else:
             return '%.1f' % self.__float__()

levels = [nf(val) for val in [1.0, 2.5,5.0,10.0] ]

pylab.clabel(cs, inline=True, fmt='%r \%%')

As I said, it's sort of a hack but it works! It might not be worth to add this to mpl, but probably as an example ...!?

Manuel

···

On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dmk@...621...> wrote:

6

Hi all,

Thanks for the comments. My sourceforge ID is dmkaplan. Please add me
as a developer. I will commit to the trunk and try to not break things,
but I am VERY new to python and it is a possibility. If things don't
work out, we can always fall back to creating a branch, though I admit
that branching and merging in subversion is a pain. And please do
notify me about stylistic issues, etc.

My contributions are likely to be a bit sporadic and selfish in the
sense that I am just adding functionality that I use all the time in
matlab. But if everyone did that, it wouldn't be half bad....

I don't think the blocking code will be that hard to maintain. It
basically just depends on events, callback functions and time.sleep. If
those are cross-platform, then it shouldn't be a problem. But only time
will tell. My ability and desire to test on multiple platforms is
limited - I use ubuntu/gnome-gtk/linux 100%.

I plan on spending today sprucing up the patch I sent. Unless anyone is
against, I will probably commit and notify in stages so that each piece
of the puzzle can be considered separately.

I have noticed that the current contour labeling code has its
idiosyncrasies, including dealing poorly with label resizing and not
being very friendly about unbreaking contours (i.e., it is currently not
possible to have a true remove method for ContourSet). I don't plan on
fixing these (at least until I have a burning desire to resize labels),
but think a contribution that allowed people to resize labels and
break-unbreak contours would be useful. I plan on compartmentalizing a
bit more ContourLabeler so that each bit of functionality is a separate
method - this should make integrating a new LabeledLine class a bit
easier as we would just need to attach the right method of one to the
other.

Cheers,
David

···

On Wed, 2008-07-16 at 10:10 -1000, Eric Firing wrote:

John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dmk@...621...> wrote:
>
>> The patch isn't done - manually selected labels won't be rotated or
>> inline. There is also a need for general cleaning up and documentation.
>> I just want to see what people think about the approach before investing
>> more time. I added this functionality by adding a class
>> ContourLabelerWithManual that inherits from ContourLabeler and
>> BlockingMouseInput (the class used by ginput to interactively select
>> points). ContourSet then inherits from ContourLabelerWithManual instead
>> of ContourLabeler. If manual is selected, then it enters interactive
>> mode, if not, then results should be as before.
>
> Hi David,
>
> I think this looks good. I would like to see it finished before
> inclusion (eg rotating the labels inline) but this functionality looks
> very useful. In general, I think it would be nice to have better
> support for easy interaction with figures, eg for annotations. My
> main question is whether blocking input is the best choice.
> Admitedly, most users find it more intuitive to set up blocking input
> rather than using non-blocking input that is terminated by a custom
> button press, key stroke, or command, but I am worried about how
> robust this is across user interfaces and environments, with all the
> attendant problems of GUI threads, mainloops, etc. Gael has done a
> nice job with ginput across backends, but this code is relatively new
> and lightly tested. Basically, someone (probably you and Gael) will
> need to be up to the task of supporting blocking input across user
> interfaces, which probably isn't trivial but maybe I'm overly
> cautious. Anyway, something to think about.
>
>> I also had to move the classes Blocking*Input from figure.py to a
>> separate file blocking_input.py to avoid circular imports.
>
> A minor nit here: when you import blocking_input, you should use
>
> import matplotlib.blocking_input as blocking_input
>
> rather than simply
>
> import blocking_input
>
> as discussed in the coding guide:
> http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html
>
> On the subject of the docs, we are in the midst of a push to get beter
> documentation for mpl, so anything you can add while working in terms
> of tutorial or faq or whatever on the new code would be welcome. The
> docs are in the doc subdir of the svn trunk.
>
>> Please let me know what you think. Also, I am wondering if the powers
>> that be would be willing to give me commit access to my own branch of
>> the matplotlib svn. I don't want to modify the trunk, but for my own
>> sanity, it would be nice to be able to keep track of my changes
>> somewhere. If not, I would like to here what other non-commit
>> developers do to best organize changes.
>
> If you send me your sf id, I will add you to the developer list. I
> don't mind you committing to the trunk unless you are afraid your
> changes will break code. I am not a huge fan of having a lot of
> branches.
>
> Thanks for the submission -- I await more informed commentary from
> those who actually use contouring....

I agree with adding the functionality provided it can be done in a
robust and maintainable way; I have never looked into the arcane aspects
of gui interaction across backends.

Unless it got fixed as part of the transforms re-write, there are
problems even with the existing contour labeling, in that it does not
(or did not) handle resizes well. Among the many things I have thought
of but not gotten to is the idea that there should be a LabeledLine
class to handle this outside of contour.py. The idea is that in
addition to the ordinary line path, it would include a list of labels
and positions (not sure what the right way to specify the positions is),
and the class would handle breaking the path and inserting the correctly
rotated text.

Eric

>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

7

Hi,

Attached is a new version of the patch that includes ginput,
waitforbuttonpress and clabel changes. It is already quite functional,
but there are a couple of issues that need improving that I would like
to solicit comments on. I explain below after detailing what I have
done.

I decided to use a slightly different approach for adding manual label
placement ability to clabel. I created a class BlockingContourLabeler
that inherits from BlockingMouseInput. This code is in
blocking_input.py. This class is called by clabel when manual mode is
selected and does the labeling by modifying the passed ContourSet object
using ContourSet methods. This avoids clouding the ContourSet
namespace with BlockingMouseInput variables and methods. Along the way,
I generalized BlockingMouseInput so that it makes it very easy to
overload methods to create the class for clabel.

In general, I think this approach is quite robust and efficient. Label
placement and coloring work perfectly. Label rotation and inlining are
usable, but not nearly as robust as the automatic versions. The main
reason for this is that I can't get my head around how the automatic
code (locate_labels and get_label_coords) works and this is preventing
me from abstracting that code into something that I can use for
non-automatic labeling. It looks to me like it breaks each contour into
n chunks, where n is the width of the label in pixels, and then places
the label on one of those pieces using the starting and ending points of
the chunk to define the label orientation. But this doesn't make much
sense to me, so I am hesitant to edit it. Somehow it works and
generally looks quite good. Perhaps someone who understands that code
can enlighten me.

In an ideal world, there would be a general ContourLabeler method that
would take the label location and spit out the appropriate rotation, no
matter where that label is. If I were to do it, I would transform the
contour to pixel space, calculate the pixel distance between points,
then use cumsum to find points around the label location that are just
greater than labelwidth/2 away along the contour path. These two
indices would define the label rotation and would be useful for breaking
contours. I can implement this, but I would like to have a better
understanding of how the current code works before modifying it.

I also made a slight modification to BlockingMouseInput that affects
ginput functioning. You can now exit out of ginput at any time using
the second mouse button, even if not in infinite mode. This agrees with
matlab functionality and can be quite useful if you want to select no
more than a certain number of points.

Cheers,
David

waitforbuttonpress_and_clabel.patch (24.7 KB)

···

On Thu, 2008-07-17 at 09:46 +0200, David M. Kaplan wrote:

Hi all,

Thanks for the comments. My sourceforge ID is dmkaplan. Please add me
as a developer. I will commit to the trunk and try to not break things,
but I am VERY new to python and it is a possibility. If things don't
work out, we can always fall back to creating a branch, though I admit
that branching and merging in subversion is a pain. And please do
notify me about stylistic issues, etc.

My contributions are likely to be a bit sporadic and selfish in the
sense that I am just adding functionality that I use all the time in
matlab. But if everyone did that, it wouldn't be half bad....

I don't think the blocking code will be that hard to maintain. It
basically just depends on events, callback functions and time.sleep. If
those are cross-platform, then it shouldn't be a problem. But only time
will tell. My ability and desire to test on multiple platforms is
limited - I use ubuntu/gnome-gtk/linux 100%.

I plan on spending today sprucing up the patch I sent. Unless anyone is
against, I will probably commit and notify in stages so that each piece
of the puzzle can be considered separately.

I have noticed that the current contour labeling code has its
idiosyncrasies, including dealing poorly with label resizing and not
being very friendly about unbreaking contours (i.e., it is currently not
possible to have a true remove method for ContourSet). I don't plan on
fixing these (at least until I have a burning desire to resize labels),
but think a contribution that allowed people to resize labels and
break-unbreak contours would be useful. I plan on compartmentalizing a
bit more ContourLabeler so that each bit of functionality is a separate
method - this should make integrating a new LabeledLine class a bit
easier as we would just need to attach the right method of one to the
other.

Cheers,
David

On Wed, 2008-07-16 at 10:10 -1000, Eric Firing wrote:
> John Hunter wrote:
> > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dmk@...621...> wrote:
> >
> >> The patch isn't done - manually selected labels won't be rotated or
> >> inline. There is also a need for general cleaning up and documentation.
> >> I just want to see what people think about the approach before investing
> >> more time. I added this functionality by adding a class
> >> ContourLabelerWithManual that inherits from ContourLabeler and
> >> BlockingMouseInput (the class used by ginput to interactively select
> >> points). ContourSet then inherits from ContourLabelerWithManual instead
> >> of ContourLabeler. If manual is selected, then it enters interactive
> >> mode, if not, then results should be as before.
> >
> > Hi David,
> >
> > I think this looks good. I would like to see it finished before
> > inclusion (eg rotating the labels inline) but this functionality looks
> > very useful. In general, I think it would be nice to have better
> > support for easy interaction with figures, eg for annotations. My
> > main question is whether blocking input is the best choice.
> > Admitedly, most users find it more intuitive to set up blocking input
> > rather than using non-blocking input that is terminated by a custom
> > button press, key stroke, or command, but I am worried about how
> > robust this is across user interfaces and environments, with all the
> > attendant problems of GUI threads, mainloops, etc. Gael has done a
> > nice job with ginput across backends, but this code is relatively new
> > and lightly tested. Basically, someone (probably you and Gael) will
> > need to be up to the task of supporting blocking input across user
> > interfaces, which probably isn't trivial but maybe I'm overly
> > cautious. Anyway, something to think about.
> >
> >> I also had to move the classes Blocking*Input from figure.py to a
> >> separate file blocking_input.py to avoid circular imports.
> >
> > A minor nit here: when you import blocking_input, you should use
> >
> > import matplotlib.blocking_input as blocking_input
> >
> > rather than simply
> >
> > import blocking_input
> >
> > as discussed in the coding guide:
> > http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html
> >
> > On the subject of the docs, we are in the midst of a push to get beter
> > documentation for mpl, so anything you can add while working in terms
> > of tutorial or faq or whatever on the new code would be welcome. The
> > docs are in the doc subdir of the svn trunk.
> >
> >> Please let me know what you think. Also, I am wondering if the powers
> >> that be would be willing to give me commit access to my own branch of
> >> the matplotlib svn. I don't want to modify the trunk, but for my own
> >> sanity, it would be nice to be able to keep track of my changes
> >> somewhere. If not, I would like to here what other non-commit
> >> developers do to best organize changes.
> >
> > If you send me your sf id, I will add you to the developer list. I
> > don't mind you committing to the trunk unless you are afraid your
> > changes will break code. I am not a huge fan of having a lot of
> > branches.
> >
> > Thanks for the submission -- I await more informed commentary from
> > those who actually use contouring....
>
> I agree with adding the functionality provided it can be done in a
> robust and maintainable way; I have never looked into the arcane aspects
> of gui interaction across backends.
>
> Unless it got fixed as part of the transforms re-write, there are
> problems even with the existing contour labeling, in that it does not
> (or did not) handle resizes well. Among the many things I have thought
> of but not gotten to is the idea that there should be a LabeledLine
> class to handle this outside of contour.py. The idea is that in
> addition to the ordinary line path, it would include a list of labels
> and positions (not sure what the right way to specify the positions is),
> and the class would handle breaking the path and inserting the correctly
> rotated text.
>
> Eric
>
>
> >
> > JDH
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************
--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

8

Hi David -- I've added you as a developer so you should be able to
commit now. The developer's guide is here:

  http://matplotlib.sourceforge.net/doc/html/index.html

Welcome aboard!

JDH

···

On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan <dmk@...621...> wrote:

Thanks for the comments. My sourceforge ID is dmkaplan. Please add me

9

Welcome aboard David!

···

On Thursday 17 July 2008 10:59:23 am John Hunter wrote:

On Thu, Jul 17, 2008 at 2:46 AM, David M. Kaplan <dmk@...621...> wrote:
> Thanks for the comments. My sourceforge ID is dmkaplan. Please add me

Hi David -- I've added you as a developer so you should be able to
commit now. The developer's guide is here:

  http://matplotlib.sourceforge.net/doc/html/index.html

Welcome aboard!

10

OK, a few comment from quickly glancing at the patch:

* What happens if twe are in a non interactive terminal, such as
  postscript? If this thing is running on a headless server, we don't
  want to hang the script because the manual option has been selected.

* Putting this argument in "*args" seems like a bad style (it looks like
  matlab). Why don't you use a "label_pos='auto'" keyword argument. This
  would be much more robust to the addition of other options, and more in
  agreement with the rest of the style of pylab's arguments.

I have to run. I haven't reviewed the patch very well. I think you should
address those two comments and send it again to the list for review.
You'll probably get useful advice and maybe learn more about Python.

Thanks,

Ga�l

···

On Thu, Jul 17, 2008 at 04:41:36PM +0200, David M. Kaplan wrote:

Attached is a new version of the patch that includes ginput,
waitforbuttonpress and clabel changes. It is already quite functional,
but there are a couple of issues that need improving that I would like
to solicit comments on. I explain below after detailing what I have
done.