|
From: Gary R. <gr...@bi...> - 2006-05-23 23:15:29
|
I did a tiny bit of work on this over the weekend too and decided to try to use a LineCollection instead of patches inspired by Chris Barker's code, but removing his polar coordinate stuff. Lines seemed a more promising way to go for the arrows, although the width should scale down when the arrows get small so that they're never wider than their length. Using a line collection may not permit this. I also haven't got it working yet. FWIW, Jordan's explanations of expected behaviour have been spot on so far. Also, I'd be happy to see the API fixed up a bit. Gary R. Jordan Dawe wrote: > >> The length of that proposed keyword is a warning flag that it may also >> be a bad design. Again, I would say either eliminate built-in support >> for color-by-length, or implement it via "color='length'", and then >> intercept that non-standard 'length' specification inside quiver so >> that it never gets passed to the standard color-handling routines. >> >> Now that you have explained it, I am inclined to either do a quick-fix >> of the present quiver so that it works again roughly as-is, or change >> the example so that it does not use the undocumented(?) "color=True" >> syntax; is one of these alternatives OK with you? Do you have a >> preference? Or do you already have an improved version that we can >> substitute now? One way or another, I don't want to leave a >> non-functioning demo in svn. > I would remove it; if we want a quiver function with color as length, we > could create a wrapper function to do that. I would lean towards making > people generate their own color array based on the array length. I'm > not going to have a new quiver anytime soon I think--a friend of mine > today pointed out that matlab distorts quiver arrows just like > matplotlib does. In matlab it isn't as noticable, however, since matlab > impliments quiver as lines instead of as polygons. In the short term, > I'm seriously tempted to just make matplotlib do the same. > > Jordan |