gmane.comp.python.matplotlib.devel

Jae-Joon Lee | 23 Sep 22:22

yet another fancy arrow, etc

Hello,

I'm working on the fancy annotation thing I mentioned the other day,
and I want to have some feedback and advice.

As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
the annotation will be consist of a fancy box + fancy arrow. And my
current plan is to put the fancy arrow things as an arrow patch class
in the patches.py. The new class would be very similar to the
FancyBboxPatch class. It will take three control points of quadratic
bezier path as an input, and will draw an arrow around this path (an
example is attached). For example

    mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
                              arrowstyle="simple",
                              ec="blue!50!white",
                              fc="blue!20!white")

But, patches.py already has three arrow classes.

 * Arrow(x, y, dx, dy)
 * FancyArrow(x, y, dx, dy)
 * YAArrow(figure, xytip, xybase)

And I'm a bit hesitating in adding yet another arrow class. One way
I'm considering is to merge my arrow class with the currently existing
FancyArrow class (or other). But their interface is a bit different
and I'm afraid that it may confuse users. So, how others think? Would
it better to simply have a seperate arrow class or to have it merged
into one of the existing arrow classes?

(Continue reading)

headers

John Hunter | 23 Sep 23:00

Re: yet another fancy arrow, etc

On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <lee.j.joon@...> wrote:
> Hello,
>
> I'm working on the fancy annotation thing I mentioned the other day,
> and I want to have some feedback and advice.
>
> As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
> the annotation will be consist of a fancy box + fancy arrow. And my
> current plan is to put the fancy arrow things as an arrow patch class
> in the patches.py. The new class would be very similar to the
> FancyBboxPatch class. It will take three control points of quadratic
> bezier path as an input, and will draw an arrow around this path (an
> example is attached). For example
>
>    mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)],
>                              arrowstyle="simple",
>                              ec="blue!50!white",
>                              fc="blue!20!white")
>
> But, patches.py already has three arrow classes.
>
>  * Arrow(x, y, dx, dy)
>  * FancyArrow(x, y, dx, dy)
>  * YAArrow(figure, xytip, xybase)
>
> And I'm a bit hesitating in adding yet another arrow class. One way
> I'm considering is to merge my arrow class with the currently existing
> FancyArrow class (or other). But their interface is a bit different
> and I'm afraid that it may confuse users. So, how others think? Would
> it better to simply have a seperate arrow class or to have it merged

(Continue reading)

headers

Jae-Joon Lee | 24 Sep 20:32

Re: yet another fancy arrow, etc

>
> Well merging is obviously better. I wrote YAArrow to support
> plain-vanilla annotations.  AFAIK, they are used nowhere else, so as
> long as we could come up with one arrow class that works with
> plain-vanilla and fancy annotations, that would be good.  But it may
> be easier said than done.  These annotation arrows are really helper
> classes that are instantiated by higher level functions (eg users most
> likely won't be creating them themselves) and since they all have the
> basic patch interface, I don't think having a proliferation of them is
> the worst thing in the world, though the ideal is to have as few
> classes as possible that serve as many cases as possible.
>
>

Thanks.
Yes, merging seems better to me too. And it seems that I can slightly
tweak the current interface of my class so that it get along well with
pre-existing classes.
I'll work on the merge and post the patch sometime soon.

>
> I believe you are looking for the scanline boolean algebra -- search
> the antigrain demo page
>
>  http://www.antigrain.com/demo/index.html
>
> for scanline_boolean.cpp.  Of course, we would need to support the
> other major backends too....
>

(Continue reading)

headers

Michael Droettboom | 24 Sep 21:09

Re: yet another fancy arrow, etc

Jae-Joon Lee wrote:
>> I believe you are looking for the scanline boolean algebra -- search
>> the antigrain demo page
>>
>>  http://www.antigrain.com/demo/index.html
>>
>> for scanline_boolean.cpp.  Of course, we would need to support the
>> other major backends too....
>>
>>     
>
> I'm not sure if scanline_boolean does what I want (but I have to admit
> that I haven't looked at its code carefully yet). Do you know if it is
> possible to stroke along the union of the two paths (this is what I
> want)? My impression is that scanline thing is for filling the path.
> Anyhow, I'll take a more look.
>   
You should probably be able to take the union of two stroked paths -- 
which is not a geometry package like lib2geom would do, but it should be 
good enough/fast enough.

Of course, any solution will have to work with all backends, not just Agg.
>   
>> This appears to be LGPL, so we will not be using it in the main distro.
>>
>>     
>
> Yes, it's LGPL.
> And I didn't mean to include it in mpl.
> Anyhow, I think I'll go with the first method for the moment.

(Continue reading)