matplotlib-devel Mailing List for matplotlib

Andrew,
Another issue.
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.
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.
Regards,
-JJ
On Thu, May 28, 2009 at 9:18 PM, John Hunter <jd...@gm...> wrote:
> On Wed, May 27, 2009 at 11:33 AM, Andrew Straw <str...@as...> wrote:
>> I've gone ahead and committed my arbitrary spine location implementation
>> to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
>> To get you started, try the new demo:
>> examples/pylab_examples/spine_placement_demo.py
>
> I just did a quick read through of the spine code and example, and
> have two minor comments.
>
> 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.
>
> 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)
>
>  @allow_rasterization
>  def draw(self,renderer):
>    "draw everything that belongs to the spine"
>    if not self.get_visible() or self.color.lower()=='none' or not
> self.color:
>      # don't draw invisible spines
>      return
>    self.artist.draw(renderer)
>
> 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.
>
> JDH
>
> ------------------------------------------------------------------------------
> 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
>

On Fri, May 29, 2009 at 9:44 PM, Petr Marhoun <pet...@gm...> wrote:
> Hello,
>
> Few days ago there were new windows binaries on Sourceforge - version
> 0.98.5.3. Yesterday I also found them in Google cache (see the
> attachment - I am interested mainly in Python 2.6).
>
> But they are not now on Sourceforge. Is there a good reason for it
> (for example there could be problematic)? Or is it a Sourceforge
> mistake (I am not sure but I think that design of the Sourceforge
> download page was different)?
>
> Maybe there is another explanation - but if it is possible, could
> windows binaries be uploaded again?
The 0.98.5.3 binaries have a problem with the PNG output, so I pulled
them. Charile, do you still have the 0.98.5.2 win32 binaries to
reupload while we are sorting out this problem?
JDH

Hello,
Few days ago there were new windows binaries on Sourceforge - version
0.98.5.3. Yesterday I also found them in Google cache (see the
attachment - I am interested mainly in Python 2.6).
But they are not now on Sourceforge. Is there a good reason for it
(for example there could be problematic)? Or is it a Sourceforge
mistake (I am not sure but I think that design of the Sourceforge
download page was different)?
Maybe there is another explanation - but if it is possible, could
windows binaries be uploaded again?
Thank you,
Petr Marhoun