[GRASS-dev] new profiling tool and other gis.m updates

[Michael Barton]

Over the past 24 hours, I've seen the following suggestions:

*******************
Zoom-in:    i or z, s or k, a or h, =, +, numpad+
Zoom-out:   o or t, x or m, s or j, -, numpad-
Pan:    p or a, a or l, f or k
Query: u, ? or q, c or n, d or l
Measure: m or d, q or o, g
Pointer: x
Redraw changes: c
Redraw everything: space
Return to previous zoom: r
Explore mode: e
Strict mode: s

F1-F12: we could even make a PDF print & cutout guide
Don't use z or y keys - due to qwerty vs qwertz keyboards.
*******************

To this, I would add that different national keyboards also make a
difference in the convenience of key combinations--e.g. French keyboards.

There are many things that we can link to hot keys (e.g., hydrological
modeling) and we can do it in many ways (use key combinations that require 2
and 3  hands to press them all). I don't think there is a lot of overhead,
but it does complicate the code somewhat.

The main issue is actually helping work flow for users, not simply doing it
because it's possible. The more hot keys there are and the harder they are
to remember, the more that the time lost looking them up will erase the
seconds saved in using them. IMHO, the place where they are most helpful are
in tasks that require many repeated switches among a limited set of
functions. 

The basic set that Trevor proposed initially--zoom in, zoom out, pan, query,
and measure--include display functions that most likely would fit the
criteria of repeated function switching (and include that probably don't
too). There seems little reason to have to switch back to the pointer tool
that doesn't do anything except display geographic coordinates in the
indicator window. I also doubt that users will be rapidly and repeatedly
redrawing the display (or at least I hope they won't). I shudder at the
thought that we'd to regress to the WordStar days of needing a keyboard
template. 

So I propose to keep this basic set in for now and see how it goes. In the
mean time, Trevor is working making hot keys more user configurable. If
successful, users can add keys for other functions and use different keys
for functions.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam at yahoo.com>
> Date: Mon, 22 May 2006 12:28:56 +1200
> To: Maciek Sieczka <werchowyna at epf.pl>
> Cc: <twiens at interbaun.com>, <michael.barton at asu.edu>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] new profiling tool and other gis.m updates
> 
>>> Using this logic the one of the obvious choices would be
>>> asfdg and hjkl; for right and left hands.
>> 
>> Not bad. But IMHO even more ergonomic is sxacq for right-handed people
>> and kmlno for left hand-handed:
>> 
>> Zoom-in: s or k
>> Zoom-out: x or m
>> Pan:  a or l
>> Query:  c or n
>> 
>> Measure: q or o
>> 
>> But I wont insinst anymore if you can tell why my proposition is bad.
> 
> 
> For folks who don't use the GUI everyday (me), the shortcut keys having
> some sort of logical reason to them makes them easier to learn and to
> remember after a week or month later when we use the GUI again.
> 
> "Blender" is an example of highly optimized software for power users
> which is fine for them, but too hard for new explorers. I think GIS
> software like grass, especially the GUI, will get a lot of explorer
> users.
> 
> I wouldn't worry too much about y,z keys being different on Germanic,
> etc keyboards. Presumably the user doesn't switch keyboards every day so
> for them it stays the same and any re-adjustment is annoying but
> non-destructive (more of a concern for a "d" delete feature option vs
> zooming).
> 
> From this thread it seems obvious that we all have our own preferences
> and a shortcut config window with key capture (any luck Trevor?) is
> required. This makes the choice of defaults less critical.
> 
> 
> 
> Hamish