[GRASSGUI] Re: [GRASS-user] Some suggestions

[Michael Barton]

Hi Micha,

Thanks for your comments.


On 6/3/07 1:05 AM, "Micha Silver" <micha at arava.co.il> wrote:

> I'm a new GRASS user. I've been aware of GRASS for many years, and
> installed version 5 some time ago, but now finally I'm "getting out of
> first gear". Since the new python based gui development is advancing, I
> think it's appropriate to throw out some comments regarding the current
> tcl/tk gui that might be improved.
> 
> 
> First: the overall structure of the application windows. I find it
> bothersome and un-intuitive having several overlapping windows to deal
> with. Each new command opens its own little window, which stays open
> after the command runs, leaving the screen cluttered. Nearly every
> computer application, on any OS, that runs in a gui will follow the
> paradigm of one application window, with menu and command buttons at the
> top, a large display area in the center, and "other" stuff (options,
> file tree etc.) along one side. I *don't* say that the new gui should
> copy the format of the commercial application from Redlands CA, but that
> format in so prevalent, and obvious that it would just make the
> day-to-day use of GRASS easier and more intuitive, rather than juggling
> thru several separate little windows. I believe that Jackym's tabbed
> options idea might address this problem somewhat.

You are talking about GRASS command properties dialogs. Almost all commands
accessible from the menu require you to set their properties (i.e., command
arguments and flags). This is just like commercial programs (e.g., MS Word
>insert>Page numbers...). Almost none of the commands work without this.

Recently, we made the properties dialogs for GRASS commands modal to see how
it would work (i.e., you could only open one at at time, and had to close it
before doing something else). This reduced screen clutter and worked like
many commercial programs. BUT, a series of comments convinced us to revert
this to non-modal use. Users commenting wanted the option of being able to
keep properties dialogs open if desired so that they could quickly alter
properties, redisplay, alter properties in another, redisplay, etc. This
means that it is up to the user to close properties dialogs and reduce
screen clutter, but offers more flexibility.

The tabs aren't related to this, but to the way to switch between open
displays. In TclTk, you simply mouse over the display to make it active. In
the wxPython one, you can click on a display OR select its tab in the layer
manager.

For a GIS, in addition to menus and buttons that work on a map or a display,
you also need controls for managing multiple map layer types and the way
that they overlay each other. Some GIS's do this by putting all this stuff
to the left (e.g., ArcGIS and QGIS); others condense the layer management
into a single place for all displays (e.g., GRASS and Map Info). The first,
puts all the stuff for a single display together, but limits the amount of
room available to display the map. The second has one extra window (layer
manager), but leaves more room in the display window for map display. GRASS
has long followed the second model. It is a bit more cluttered if you are
looking at one map, but less so if you are looking at more than one.

> 
> 
> Second: Currently (tcl/tk) the menu items appear as a long string
> describing what each command does. These descriptions to my mind are
> unnecessary and confusing, whereas the actual command names are short
> and obvious. (Again, I'm speaking as a new user). What is "Color balance
> and enhance color tables of multiband imagery for rgb display"? Once I
> open the  options window, and I see that it's i.landsat.rgb, then I
> understand...  Another example: Why say  "Carve stream channels into
> elevation map using vector streams  map" ? The actual command name
> "r.carve" is very clear. The proper place for the longer verbal
> explanation of each command is in tool-tips that appear when hovering
> over a menu item or button. The menu items should be 1-2 words at most,
> often the command name itself.

I'm glad that you understand quickly what i.landsat.rgb does, but many users
(like me) can't remember what every command does and most new users will
have no idea. If I look at my email program open now (made by the folks at
Redmond), menu items look like "After sending, Move to...", "Turn off Office
notifications", etc. Shorter menu items are highly desirable and suggestions
are most welcome. It's just that some command functions are difficult to
clearly describe in a couple of words.

> 
> 
> Third: I'd like to see a fully interactive terminal window as part of
> the main application window. Again I think Jachym is addressing this
> question. I saw a poll not long ago asking GRASS users if they used
> mostly the command line, the gui or QGIS. I think the consensus was that
> most switch back and forth between the gui and the command line. So
> there's no doubt in my mind that an interactive terminal window should
> be part of the gui, along the bottom, probably. Each menu chosen command
> should appear in the terminal, and the user should also be able to edit
> these commands, use the shell's command history, etc. And the command
> output should also appear here. In other words this command line should
> replace the current output window, with the additional capability of
> interactive use.

Currently, you have most of what you are asking for in the TclTk console (as
well in the wxPython console). For TclTk, all commands are echoed to the
console, which maintains a history. You can click on any echoed command and
it will appear in a command entry box at the bottom, where you can edit and
run it again. You can also type commands here. You can also type any other
shell command that doesn't require interaction and it will run (e.g., you
can type ls, cp, mv, xeyes, etc).

What is missing is a fully interactive terminal--one that will prompt you
for entries and you can respond. This is doable in both TclTk and Python,
however several have questioned the worth of going to the trouble to do
this. A terminal of this kind is always available on *nix systems and is of
little value on a Windows systems.

Hope these explain the rationale behind this part of the design. Thanks for
the input. 

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