The present NavigationToolbar2 is very nice, but I am thinking about an improvement: adding a button that would rotate a constraint among three possibilities, so that pan/zoom and rectangle select could be set to affect only X, only Y, or be left unconstrained as at present.
The problem with the present system is that often one really wants to pan and zoom in only one direction, or at least one direction at a time. For example, I have a dataset consisting of 10000 profile measurements (increasing with time on the X-axis) with 20 vertical bins. I want to display the whole thing with pcolorfast, and then zoom in on particular sections to the point where the individual profiles can be seen clearly. Doing this with the present pan/zoom and rectangle tools is awkward--I am not coordinated enough to move the cursor perfectly horizontally, or to select a rectangle that goes exactly from top to bottom. I suspect that there are many data analysis applications like this, where one wants to vary only one dimension at a time.
Although there might be more elegant ways to do it, I think the simplest way to get this functionality across backends would be to add a single button that rotates a variable among values of 'X', 'Y', and 'XY', and then let that variable constrain the effects of pan/zoom and rectangle-select. It would be nicer, but more work, to have the variable change the rubberband to a span-select in the latter case; I am inclined to start with the easiest implementation I can come up with. I think the simple approach can be done with only a little bit of change in the backends.
Comments? Objections?
This could also be done by making a NavigationToolbar3, but I think that even with inheritance from NavigationToolbar2, this would require more work.
Eric
Hi Eric,
The present NavigationToolbar2 is very nice, but I am thinking about an
improvement: adding a button that would rotate a constraint among three
possibilities, so that pan/zoom and rectangle select could be set to
affect only X, only Y, or be left unconstrained as at present.
[...]
Although there might be more elegant ways to do it, I think the simplest
way to get this functionality across backends would be to add a single
button that rotates a variable among values of 'X', 'Y', and 'XY', and
then let that variable constrain the effects of pan/zoom and
rectangle-select.
I would prefer to not add a button to change the behavior of other buttons,
but rather stack three buttons (XY,X,Y) for pan and zoom, perhaps selectable
from a drop-down widget of some kind, so you can select which version of
pan/zoom you want.
It would be nicer, but more work, to have the
variable change the rubberband to a span-select in the latter case; I am
inclined to start with the easiest implementation I can come up with. I
think the simple approach can be done with only a little bit of change
in the backends.
That would be nice, maybe for a future addition.
Comments? Objections?
This could also be done by making a NavigationToolbar3, but I think that
even with inheritance from NavigationToolbar2, this would require more
work.
I recently subclassed NavigationToolbar2 to add a crosshairs button. I have
multi-dimensional data and I wanted to click on a point in an image to create
an associated projection. I had to reimplement several of the toolbar2
methods with minor changes to support an additional button. I wonder if we
could come up with a toolbar that was easier to subclass without
reimplementing so much of the machinery. I won't have time to pursue this
until summer, just throwing it out there.
Darren
···
On Sunday 13 April 2008 7:39:14 pm Eric Firing wrote:
I assume you know that for panning and zooming, if you hold down the
'x' key the pan/zoom is constrained in the horizontal direction and if
you hold down the 'y' key it is constrained to the vertical direction.
It would not be hard to add support using these keys to the
zoom-to-rect. Do you think having a toggle button adds more than
simply using these key presses?
I do think Darren's suggestion of making the toolbar more easily
extensible and configurable is a good one. A colleague of mine
recently wanted to change the icons, drop a couple of buttons, and add
a couple of new ones, and I think he ended up just pasting in the code
for NavigationToolbar and modifying what he needed. Not very
attractive from a design persepcetive.
JDH
···
On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <efiring@...229...> wrote:
The present NavigationToolbar2 is very nice, but I am thinking about an
improvement: adding a button that would rotate a constraint among three
possibilities, so that pan/zoom and rectangle select could be set to
affect only X, only Y, or be left unconstrained as at present.
John Hunter wrote:
The present NavigationToolbar2 is very nice, but I am thinking about an
improvement: adding a button that would rotate a constraint among three
possibilities, so that pan/zoom and rectangle select could be set to
affect only X, only Y, or be left unconstrained as at present.
I assume you know that for panning and zooming, if you hold down the
'x' key the pan/zoom is constrained in the horizontal direction and if
you hold down the 'y' key it is constrained to the vertical direction.
It would not be hard to add support using these keys to the
zoom-to-rect. Do you think having a toggle button adds more than
simply using these key presses?
Aha! Evidently I *should* have known, but I *didn't* know, about the x and y keys. Sounds more and more familiar now, so I'm sure I saw some reference to it quite a while ago. Strangely, I did not stumble over it yesterday or today when looking at the code from the standpoint of making the proposed change.
The toggle button would make it more obvious that the constraint options exist, and would make the operation easier on my laptop with the trackpad, but it is much less tempting now that you have reminded me of the keys. On the other hand, given that the basic functionality is already there with the keys, it would presumably be easier than I thought to add the button--although Darren doesn't like that interface design, and he may have a good point.
Adding the key support to the zoom-to-rect definitely would help.
I do think Darren's suggestion of making the toolbar more easily
extensible and configurable is a good one. A colleague of mine
recently wanted to change the icons, drop a couple of buttons, and add
a couple of new ones, and I think he ended up just pasting in the code
for NavigationToolbar and modifying what he needed. Not very
attractive from a design persepcetive.
I agree entirely that it would be nice if it were easy for a user to pop buttons in or out of the toolbar. I'm glad Darren is interested; it is not something I would be likely to pursue myself. Too hard, with all the gui backends.
Eric
···
On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <efiring@...229...> wrote:
JDH
John Hunter wrote:
>
> > The present NavigationToolbar2 is very nice, but I am thinking about an
> > improvement: adding a button that would rotate a constraint among three
> > possibilities, so that pan/zoom and rectangle select could be set to
> > affect only X, only Y, or be left unconstrained as at present.
> >
>
> I assume you know that for panning and zooming, if you hold down the
> 'x' key the pan/zoom is constrained in the horizontal direction and if
> you hold down the 'y' key it is constrained to the vertical direction.
> It would not be hard to add support using these keys to the
> zoom-to-rect. Do you think having a toggle button adds more than
> simply using these key presses?
>
Aha! Evidently I *should* have known, but I *didn't* know, about the x and
y keys. Sounds more and more familiar now, so I'm sure I saw some reference
to it quite a while ago. Strangely, I did not stumble over it yesterday or
today when looking at the code from the standpoint of making the proposed
change.
It is mentioned in the tutorial
http://matplotlib.sourceforge.net/tutorial.html#toolbar2 and in the
"toolbar2" section if the user's guide. There are other nifty nuggets
in there, like zoom to point in the zoom mode.
Adding the key support to the zoom-to-rect definitely would help.
This seems like a god piece of low hanging fruit. Another feature
that a couple of folks have mentioned to me off list would be in an
constrained zoom to rect, to have the ylim (optionally) autoscale over
the y data in the zoomed region.
JDH
···
On Sun, Apr 13, 2008 at 9:37 PM, Eric Firing <efiring@...229...> wrote:
> On Sun, Apr 13, 2008 at 6:39 PM, Eric Firing <efiring@...229...> wrote: