On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Well, I now know more than I ever wanted to about clabel. I decided to
> improve a bit on the inlining and ended up rewriting it. For automatic
> label placement, I basically use the existing algorithm for determining
> label location, but have replaced existing code for determining the
> angle of rotation and the amount of the contour to take off for inlining
> with new code. This new code is based on using pixel-space distances
> along the contour. This allows one to (1) get nice balanced inlining
> with the same amount of space on either side of the label, and (2) to
> vary the amount of space you want around the label. It also should deal
> better with labels located near contour edges and labels covering the
> entire contour.
>
> Along the way, I renamed all ContourLabeler specific attributes to
> something like .labelAttribute. This makes the namespace cleaner in my
> mind, but might break existing user code that does things directly with
> ContourLabeler attributes.
Eric, do you have any sense of whether people would use this directly?
Since this is a point release, I want to minimize API breakage, so at
least keep the old attrs around for this cycle. Eg, in Axes I
recently renamed axesPatch to simply patch as follows:
# the patch draws the background of the axes. we want this to
# be below the other artists; the axesPatch name is deprecated
self.patch = self.axesPatch = self._gen_axes_patch()
we don't have an easy way to catch deprecated usage w/o some property
or getattr magic. If you want to add getter properties for the
deprecated attrs which warn and point to the new, that would be ideal.
> I also added a few new functions to cbook. One does simple linear
> interpolation (in addition to an existing cbook function that is similar
> but a bit different). Others do things with vector lengths. I also
> added a function called isvector that is identical to a Matlab function
> of the same name. If desired, I can move this to mlab.py, but for the
> moment it is in cbook.py because most of the is? functions are there.
That's fine. Is this different from "iterable"
> On an aside, I noted that mlab.norm uses cut-and-paste documentation
> from Matlab. Is this wise?
No, please rewrite the docstring. Some of mlab was borrowed form
other people's codes, and I was unaware of this.
> I have tested all the changes against the existing pylab_examples and
> things work fine. Nonetheless, since lots of things have been changed,
> I haven't committed them for fear of interfering with the release.
> Instead, I am attaching the patch set. If I get the green light, I will
> commit these changes.
I'll leve the final call on this to Eric, but after this I suggest we
implement a feature freeze until after we get the current code tested
and out. Friday is a reasonable target if others agree and we have a
chance to test this for a couple of days.
> Related: while I am digging around in there, now is probably the moment
> for me to integrate Paul Kienzle's comments on start/stop_event_loop in
> FigureCanvasBase, etc. I am not sure there is a consensus on this. I
> am currently thinking that the best way to integrate this, while
> minimizing repeated code, is a mixin plus a couple of new classes,
> FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
> inherit the mixin and the base classes without "GUI". Interactive
> backends would then inherit these. Non-interactive backends would
> inherit versions that throw errors from FigureBaseCanvas. Complex, but
> this assures clean inheritance. Thoughts welcome.
See my response in the original thread. I'm not sure we ever reached
a consensus on this one, and I'm still uncomfortable with a more
complex hierarchy. I'm willing to be convince if you and Paul and
Gael disagree, but I have yet to see why a flat implementation will
not work here.
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
