[GRASS5] Zoom

[Radim Blazek]

On Friday 19 April 2002 06:33 pm, you wrote:
> I don't think an initial menu that chooses between zoom/pan is very
> useful. This requires two extra clicks for every complete zoom
> operation, (one to choose zoom instead of pan, and another to finally
> quit).
> Instead, I would make d.zoom and d.pan be separate commands.

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. 
As a solution, I suggest to add optional flag, which would skip the
main menu, and start in zoom menu directly. 

> 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.

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

> Finally, as a general point coming from a developer interested in
> designing better user interfaces for GRASS: If higher-level
> user-interfaces are going to be able to make use of GRASS commands
> rather than re-implementing everything, then those commands should
> provide functionality without interface, (think mechanism not
> policy). For example, d.zoom should provide the functionality of
> zooming in once. Things such as repeating another zoom, canceling the
> last zoom, etc. should be up left available for the high-level
> user-interface designer to implement as appropriate.

Optional quit after one zoom, should not be problem.

> The current, (and proposed), d.zoom commands don't follow this
> guideline, and hence would be of limited use to a higher-level
> user-interface.

But should not block future addition of that features, or yes?
My question is, if the last change is step back, or it can limit 
us somehow in future. 

> In the ideal case, what I would like to see is:
>
> 	d.pan -- Click button one to pan center point
> 	d.zoom -- Click-and-drag button one to zoom in
> 	d.unzoom -- Click button one to unzoom step-wise

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.

BTW: How do you use d.zoom on handheld? Do you have your special
version of d.zoom for one button or do you use aditional buttons 
on handheld?

> Reactions?

I am also waiting for more reactions, we can fix bugs in future,
but we should not change d.zoom behaviour after release.


Radim