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


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