[GRASS5] Zoom

[Carl Worth]

On Apr 22, Radim Blazek wrote:
 > On Friday 19 April 2002 06:33 pm, you wrote:
 > I know about that two clicks, but I could not find any other
 > way, how to get pan and zoom to one module, which I consider to be
 > useful. 

I'll propose another solution below.

 > > And, ideally, I would also like to have a mechanism by which zoom and
 > > unzoom could be performed with a one-button pointer, (I often use
 > > GRASS on handheld computers with a touchscreen). One thing that would
 > > make this quite nice would be a mechanism for doing a click-and-drag to
 > > select rectangular regions rather than the current two-click
 > > style. That will require changes to the display driver, (simply needs
 > > a function to request a rectangle rather than a point).
 > 
 > Do you want this as standard behaviour or optional "one-button mode"?
 > It would be a pity don't use all buttons if there are available.

Ideally, IMHO, each command could perform its advertised function with
a single button. Hence, I would like to be able to use both d.zoom and
d.pan with a single button.

If a command has some sort of "extra" functionality that requires
multiple buttons, (such as panning from with d.zoom), then that's OK
too. This way, users with one button can get all the functionality,
(since both d.zoom and d.pan are available), and users with multiple
buttons could still make use of them, (by doing everything within
d.zoom for example).

 > Just a question: is it possible on handheld to use click-drag-click
 > instead of click-drag now?

With most handhelds with which I am familiar, the only pointer is a
touchscreen with a dumb stylus. With this system, the only motion
events available are those for which a button is pressed. That is, you
*can* use the handheld to specify a rectangle using two "clicks", but
the program will not get any motion events between the clicks, (and
therefore cannot provide the typical rubber-banding feedback that is
quite useful when drawing rectangles).

In order to get rubber-banding for rectangles with this type of
touchscreen, a click-and-drag motion would be necessary. As mentioned
elsewhere, this would be a significant modification to the current
display driver, but I'm willing to investigate this.

 > I would suggest:
 > d.zoom -p : Click button one to pan center point
 > d.zoom -w : Click-and-drag button one to zoom in
 > d.zoom -u : Click button one to unzoom step-wise
 > 
 > Should not be problem to call by user interface.

I guess those would work. But, I would prefer naming the functionality
"d.pan" rather than "d.zoom -p". I'm a big fan of making interfaces
that actually name the functionality being provided.

When it comes down to it though, it may be that the user-interface
should really uses library calls rather than invoking commands. If
that were the case, then we could let the commands cater to what users
want rather than what the user-interface wants. But, the code is
certainly not in that state currently, (eg. d.zoom contains a lot of
actual code rather than a couple of calls to some D_zoom operations).

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725