matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
> Andrew Straw wrote:
>> The slight API change is that spine.set_color() is now
>> spine.set_edgecolor().
> 
> But spine.set_color() is much more natural and easy to remember, so 
> maybe it can be restored:
Good idea. I just re-added Spine.set_color() and changed the example back.
-Andrew

Andrew Straw wrote:
> Thanks everyone for the feedback. I have made Spine subclass Patch in
> svn r7170, which I just committed. This resulted in a slight API
> change, but addresses most of the more substantial points raised.
> 
> The slight API change is that spine.set_color() is now
> spine.set_edgecolor().
But spine.set_color() is much more natural and easy to remember, so 
maybe it can be restored:
Collections have had a set_color() for a long time, and I don't see any 
reason Patch shouldn't have the same, so I added it. My first thought 
was that this would have no effect on spines except to permit the 
alternative and more natural "spine.set_color()" to work like 
set_edgecolor, but now I see that this is not true--in the case of a 
circular spine, calling set_color(c) would have the unintended effect of 
filling the circle. I still think having the set_color method in Patch 
and Spine is good, so what I propose is that Spine override the Patch 
version with a simple alias to set_edgecolor.
Eric

Thanks everyone for the feedback. I have made Spine subclass Patch in
svn r7170, which I just committed. This resulted in a slight API
change, but addresses most of the more substantial points raised.
The slight API change is that spine.set_color() is now
spine.set_edgecolor().
More below.
> On Thu, May 28, 2009 at 9:18 PM, John Hunter <jd...@gm...> wrote:
>> You do an isinstance(arg, basestring) to check for string input.
>> Typically, we encourage cbook.is_string_like to have a central point
>> of maintenance and consistency for these checks.
fixed in r7169
>> Also, in the example, you appear to turn off a spine by setting the
>> color to 'none'. My thought it would be more natural to use the
>> "visible" artist property here (or at least support both)
I think this is addressed naturally by the new "Spine is a Patch" behavior.
>> Also, I think the class of strings representing "no color" in mpl is
>> larger -- it should also include self.color.lower()=='none' and the
>> empty string, which I've included in the example code.
Same for this. Now there's a single point of failure in the Patch.draw()
method.
Jae-Joon Lee wrote:
> The zorder of the spine artists is set to 0 by default.
> I notice that you're changing the zorder of its artist attribute, but
> note that it has no effect as what matter is the zorder of the spine
> itself.
Again, I think this is dealt with by the "Spine is a Patch" patch.
> As a related issue to what John mentioned, I think one option you can
> do is to derive the Spine class itself from a real artist class,
> rather than the base "Artist". With this, you don't need to implement
> all other set/get method, e.g., color, etc. For example, you may
> derive it from the Patch class. Note that while the Patch class is
> intended for closed path, you can stroke a straight line with it.
Good idea -- done! :)
 > * cla() does not reset spines (positions, color, etc). I think it is
> better to be reset, since all other things are. For example, cla()
> resets visibility of ticks, etc.
Nice catch. Fixed in r7168.
> * better support for log scale.
I see the issue here, but I haven't had a chance to fix it. To be
honest, I'm surprised there aren't more of these types of issues...
You're welcome to take a look if you're so inclined -- it'll probably be
a few days before I have a chance to look at it.

Michael Droettboom wrote:
> I'm +1 on dropping support for gtk+ < 2.4 (if even later). Those 
> multiple code paths were a pain, and installing multiple versions of 
> gtk+ for testing is also something I'd like to stop doing.
> 
> Cheers,
> Mike
Done.
Eric
> 
> Eric Firing wrote:
>> We still require only gtk 2.2, and consequently carry around some 
>> extra chunks of code to support versions before 2.4. Can we drop this 
>> and require 2.4 or later? Or possibly even a later version? It looks 
>> like 2.4 came out in the fall of 2004.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------ 
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
>> iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian Group, R/GA, & Big Spaceship. 
>> http://p.sf.net/sfu/creativitycat-com 
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

I'm +1 on dropping support for gtk+ < 2.4 (if even later). Those 
multiple code paths were a pain, and installing multiple versions of 
gtk+ for testing is also something I'd like to stop doing.
Cheers,
Mike
Eric Firing wrote:
> We still require only gtk 2.2, and consequently carry around some extra 
> chunks of code to support versions before 2.4. Can we drop this and 
> require 2.4 or later? Or possibly even a later version? It looks like 
> 2.4 came out in the fall of 2004.
>
> Eric
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA