Ahhh - Thanks! I was wondering if both axes would scale when
> doing a zooming operation but I hadn't had time to try it
> out. Thanks for the example, that's exactly what I was
> looking for.
>> On the contrary, you should use twinx for that, as follows:
Baptiste, this is an exceedingly clever solution which wouldn't have
occurred to me, but I suspect it is a clever hack designed to work
around a design flaw. One shouldn't have to be so clever to do
something so simply stated as Ted's original request. Would it not be
better to support (optionally) a different tick labeler and formatter
for bottom/top and left/right?
But this too is the wrong question....
In truth, what we want is to be able to have an arbitrary number of
Axis lines, each with their own tick locator and formatter, which can
be placed at an arbitrary location (arbitrary for an x-axis means a
horizontal line at an arbitrary y-location which spans the x data
range). In this view, the current y=0 for bottom and y=1 for top are
just two special cases for the x-axis; in general we want to be able
to place these suckers anywhere and to control their tick locating and
formatting independently.
This raises the question of how we should specify the location of the
axis line. For concreteness, let's just consider the x axis line and
how we should specify its y location. In the current implementation,
there are only two possible y locations, at 0 and 1 for bottom and
top. Most of the time, this is just what you want, eg, you want the
axis line to remain fixed at the bottom when changing the y pan or
zoom. But it seems that sometimes you also want the y location of the
x axis to be placed in data coords, and sometimes you want it in
places other than the top and bottom.
Several use cases point to the need to make the axis line (and it's
associated ticks and labels) independent objects that can be
customized. In particular, I have seen Eric Jones demonstrate in
Chaco several times the ability to have multiple y axis objects --
apparently this is something frequently needed in the petroleum
industry. Also, Andrew Straw has posted examples in which he wants to
decouple the axis line from the rectangular box defining the data
clipping box.
When this issue came up previously, I've noted that this is a good use
for traits. But lazy values, properly utilized, could serve as well.
The basic problem to be solved is that we need to have a mechanism so
that when an axis line is moved, eg by a set call at the user level,
the associated ticks and labels move with it. Whether this is done
with traits observer/delegation or shared lazy values is not too
important.
But a refactoring of axis, tick and labeling is long overdue...
JDH