arrow 1/50th the width of the plot. Change the window
> width, and the arrow length changes along with it. Zoom,
> and it does not change, however. In all cases, the arrow
> direction remains constant, regardless of window or view
> limit manipulations. (This is all because of John's
> transform magic--it is a little hard to understand at first,
> but it certainly provides wonderful functionality.)
Hey someone said something nice about transforms!
Eric, I haven't had a chance to try this code out but I did read
through it and it looks very nice. A small comment: fig.dpi is
already a Value, so I don't think you want
+ elif self.units == 'inches':
+ dpi = ax.figure.dpi.get()
+ dx = T.Value(dpi)
because that is copy semantics and you probably want reference
semantics
+ elif self.units == 'inches':
+ dx = ax.figure.dpi
That way if someone changes the figure dpi. Or maybe I'm missing
something and you really want copy.
fig.dpi.set(72.)
all of your transforms are automagically updated.
Is there any reason not to commit this to svn? It seems to live in
parallel with the existing quiver, so shouldn't cause anyone any
grief.
JDH
JDH
Hey someone said something nice about transforms!
About time, isn't it!
One thing I still don't understand: when is it necessary to bracket code with freeze/thaw?
Eric, I haven't had a chance to try this code out but I did read
through it and it looks very nice. A small comment: fig.dpi is
already a Value, so I don't think you want
+ elif self.units == 'inches':
+ dpi = ax.figure.dpi.get()
+ dx = T.Value(dpi)
because that is copy semantics and you probably want reference
semantics
+ elif self.units == 'inches':
+ dx = ax.figure.dpi
That way if someone changes the figure dpi. Or maybe I'm missing
something and you really want copy.
You are right--the copy was a blatant bug, and I'm glad you caught it.
fig.dpi.set(72.)
all of your transforms are automagically updated.
Is there any reason not to commit this to svn? It seems to live in
parallel with the existing quiver, so shouldn't cause anyone any
grief.
I was holding off so as not to confuse things by making a big change during a version release; Charlie indicated that this was his preference. Is the release packaging occurring today?
If you want me to go ahead and commit, I am happy to do so. The idea would be that quiver2 is an experimental version, subject to more changes (e.g., addition of dots when arrows get too small; maybe changes in kwarg function and naming, if someone has better suggestions), but that it would replace the old quiver, perhaps at the next major release point. This is also Charlie's suggestion, and I agree with it. We need to clean things up occasionally, and not keep accumulating alternative versions of things. In that vein, can we drop pcolor_classic before the next major release?
Eric