[GRASSGUI] Some suggestions

[Micha Silver]

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.


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.


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.


Sorry for the long post. And If I'm "breaking into an open door", i.e.
if these suggestions are already being implemented then a double "Well
Done" to the contributors.


Regards,

Micha

[Michael Barton]

Hi Micha,

Thanks for your comments.

Post by Micha Silver
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

Post by Micha Silver
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.

Post by Micha Silver
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.

Post by Micha Silver
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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

Thanks for the ideas Hamish

..

Post by Micha Silver
First: the overall structure of the application windows. I find it
bothersome and un-intuitive having several overlapping windows to
deal with.

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.

could there be a "keep alive" checkbox in the module GUI windows that
would ^Z,bg fork the window when [Run] was hit? Otherwise the GUI closes
after a "Operation Complete" [Ok] dialog.
?

Switching back and forth from modal to non-modal is just one line of code.
Having a checkbox in each properties dialog may be the way to go (Daniel?).
It would default to a modal operation, but could be changed by the user on
an as needed basis. Getting the buttons to change at that moment probably is
not possible. An alternative would be to come up with a general GRASS config
settings dialog--long needed but never done.

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.

back to the idea of start with one window but allow tear-away. I expect
folks with multi-head displays will want the map display in a window in
one monitor and the controls in the other (original GRASS design AFAIK),
without having to tear-away manually each time. no idea what support is
like for this in wxPython.

I'm checking to see if it's possible to start with 2 windows and dock the
layer manager if desired.

The issue for going the other way is that the layer manager (AKA GIS
Manager) controls all displays, which can be very handy. Having it start out
inside one display is a problem for the other displays. Making each display
control its own layers is quite doable but means programming this all in a
very different way. But doing this makes putting them back together into a
single layer control very hard or impossible (AFAICT). Having a tear off
layer manager for each display would *really* make for a cluttered screen.
There wouldn't be much reason for the tear off manager in this case.

Post by Micha Silver
Second: Currently (tcl/tk) the menu items appear as a long string
describing what each command does.

AFAIK tcl does not allow tooltips on menu items. Maybe this is different
for wxPython? Note the command name shows up on the bottom line of the
GIS Manager window as you pass through the menus.

Post by Micha Silver
Third: I'd like to see a fully interactive terminal window as part
of the main application window.

..

Currently, you have most of what you are asking for in the TclTk
console

suggestion: the "Output" window's interactive box (lower) should have
some caption indicating its existence, or include a prompt GRASS> + take
[Enter] to mean Run. see the GRASS prompt in the QGIS grass toolbox.

Good idea and quite doable. In TclTk, there is the run button. But in
wxgrass, the command enter box is very 'subtle'. Make sure and remind me
about this if it slips my mind (busy week coming up).

What is missing is a fully interactive terminal--one that will prompt
you for entries and you can respond.

GRASS_UI_TERM=1 i.landsat.rgb
does, but output to tcl/python code not in the xterm?

No. More like being able to enter g.setproj and answer the prompts. We can
create a full-fledged terminal in wxPython I think. But it's not clear if
there is a real advantage to working out the coding to do so given the
presence of terminals in *nix and their minimal utility under pure Windows.
If we start using Python big time, however, it could be worth thinking about
a Python terminal for all. But this is different from a standard *nix
terminal. But maybe we're talking past each other here.

Michael

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Jarek Jasiewicz]

Generally If I can add one sugestion:

First it very simple: add some quick coomand for example the probably
most ofen used command is g.region res=xx

maybe small field around display manager allow to change resolution
without opening the dialog, choosing proper tab etc.. will be good idea?

Jarek

[Michael Barton]

There is a command prompt at the bottom of the layer manager (AKA GIS
Manager) window.

You can just type in simple commands (or complicated ones for that matter)
without having to open the properties dialog. Currently you can't type in
any display commands and have the result show up in the map display, but
this is because that feature is broken, not because it is not intended to be
there. All other commands work fine--including unix shell commands.

Following up on a suggestion by Markus, I added a command prompt to make it
more obvious.

Michael

Post by Jarek Jasiewicz
First it very simple: add some quick coomand for example the probably
most ofen used command is g.region res=xx
maybe small field around display manager allow to change resolution
without opening the dialog, choosing proper tab etc.. will be good idea?
Jarek

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Jarosław Jasiewicz]

Post by Michael Barton
There is a command prompt at the bottom of the layer manager (AKA GIS
Manager) window.
You can just type in simple commands (or complicated ones for that matter)
without having to open the properties dialog. Currently you can't type in
any display commands and have the result show up in the map display, but
this is because that feature is broken, not because it is not intended to be
there. All other commands work fine--including unix shell commands.
Following up on a suggestion by Markus, I added a command prompt to make it
more obvious.
Michael

Post by Jarek Jasiewicz
First it very simple: add some quick coomand for example the probably
most ofen used command is g.region res=xx
maybe small field around display manager allow to change resolution
without opening the dialog, choosing proper tab etc.. will be good idea?
Jarek

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

Yes, and I do that. See

"g.region res=xx"

I rather think about max simplifing most popular comamand in one place


BTW:
Why, if some make suggestion, for example "Maybe that solution will be better..." the answer mosttly is: "You can do that by typing....", but not: "it is silly idea becouse..." or "it good idea but it requiers lot of work, so rather not now..." or "its good idea, and we can think about it..." or "yes, but maybe that way it will be better..."


No everbody ansver "how can I do that...", somebody also suggest: "mabye another way will be better..."

Jarek

Jarek