On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> 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....

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

Reply via email to