[GRASS-user] 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

[cmbarton]

Hi Micha,

Thanks for your comments.

On 6/3/07 1:05 AM, "Micha Silver" <micha@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

[H_B]

Micha Silver wrote:

..

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

Michael:

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

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.

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

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

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

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

Hamish

[cmbarton]

Thanks for the ideas Hamish

On 6/4/07 2:56 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Micha Silver wrote:

..

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

Michael:

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.

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.

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.

Do you mean like:
  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: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

[Tim_Michelsen]

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.

I think that this is a crucial point.
There should definately a option to run all Grass sub-windows all in one master windows.
Maybe others like their screen cluttered but especially newbie for whom the new GUI is a *real* improvement will get confused.
Don't forget that besides Grass users may also use a folder browser, terminal and mail application at the same time. And now that Grass is being ported to Windows don't forget that Windows doesn't have virtual workspaces like Gnome, KDE, etc.!

You may compare it to the disussions going on about the interface of Gimp & Photoshop. Here are some impressions what users do to run Gimp in 1 window:
HOWTO: Run GIMP in its own window. - http://ubuntuforums.org/showthread.php?t=240543&highlight=gimp+howto

Many huge open source projects have usability commitees or guidelines beyond the general workflow for the specific application.
Are such issues considered by the development team?

Please consider Jarek's concern. We all want to get FOSS4G more mainstream. I think that Ubuntu is streamlined towards usability and really easy to use [please, I am not starting a distro flame here!] and is based on another popular distribution: Debian. So we need users from OpenSuse or Fedore to have a word on this (wxPython) . It would certainly not be desireable that there'll be one more package (wxPython) which a user who wants to use latest Grass developments has to install to benefit fully.

I want to pay my tribute to this new GUI. Really a step forward!

Kind regards,
Tim

[H_B]

Michael:

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.

I'm thinking about a dual monitor setup, you have a display window and
associated control window in each. Effectivly concurrent use of the same
mapset. .. just an idea ..

M:

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

H:

> Do you mean like:
> GRASS_UI_TERM=1 i.landsat.rgb
> does, but output to tcl/python code not in the xterm?

M:

No. More like being able to enter g.setproj and answer the prompts.

G63> GRASS_UI_TERM=1 i.landsat.rgb

OPTION: LANDSAT red channel
     key: red
required: YES

Enter the name of an existing raster file
Enter 'list' for a list of existing raster files
Hit RETURN to cancel request

?

We can create a full-fledged terminal in wxPython I think.

..

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.

Offering a python terminal is a very nice idea. Then you get access to
all grass commands + SWIG access to the libgis fns in a safe, platform
consistent way.

Maybe package the module families as import r.py, v.py, g.py etc, so
"r.module" links to [r.]r.module. much better than:

import os, popen2
command = 'ls'
child = os.popen(command)
data = child.read()
child.close()

[maybe easier with the subprocess module or something already written
for the wxPyGUI? (no idea about python)]

Hamish

[cmbarton]

Tim,

Thanks for the input. Much of this was discussed awhile back when we went
through a design process. Here are some thoughts.

On 6/4/07 12:05 PM, "Tim Michelsen" <timmichelsen@gmx-topmail.de> wrote:

I think that this is a crucial point.
There should definately a option to run all Grass sub-windows all in one
master windows.

An MDI hearkens back to Windows 95 and gets to be a real problem if you want
to have multiple displays open. In most commercial software and a lot of
Open Source packages today, you get a complete new window when you open a
second instance of the application.( e.g., open a second document in MS Word
or a second message in Apple Mail). They are not all grouped within a single
master window. It is easier for most people to move separate windows of
multiple instances around rather than having to scroll within a master
window. Each GRASS map display is like a new instance of the application.

Maybe others like their screen cluttered but especially newbie for whom
the new GUI is a *real* improvement will get confused.
Don't forget that besides Grass users may also use a folder browser,
terminal and mail application at the same time. And now that Grass is
being ported to Windows don't forget that Windows doesn't have virtual
workspaces like Gnome, KDE, etc.!

The basic GRASS application design is a minimum of one display and one layer
manager window. Every new instance (new display) adds only one more window
because the single layer manager works for all displays

Each display needs layer management, which takes up a fixed amount of
horizontal space (due to the width of layer names, on/off checkbox,
icon/button to ID layer type and launch properties dialog). If you
permanently attach a layer management window to each display, every display
window must be that much larger (or the display area of the window that much
smaller). You also waste additional vertical space in the layer manager area
when the display is considerably higher than the layer manager needs to be.
This is often the case unless you have a LOT of layers contributing to a
single display.

If you compare the current design with one that permanently attaches a layer
management window to every display (e.g., ArcGIS), the current design saves
considerable screen space relative to the amount of map displayed if you
want to display more than one set of maps. For displaying only one set of
maps, it may lose a little space (though not much since the layer manager is
shorter than the map display usually and also doubles as a command line
terminal).

That said, it could be convenient to attach/dock a map display to the layer
manager, in order to move them around together. I'm looking into a way to do
that. May or may not be possible.

This is not referring to the properties dialogs for each GRASS command.
These are unavoidable if you want to run the command, but can be closed to
clean up the screen. Press OK instead of Apply and the window goes away.
Grouping them into a single MDI wouldn't make them any easier to work with
or less cluttered. Hamish has suggested making them modal by default, with
the option of keeping them open if you want via a checkbox. This sort of
forces you to keep your screen clean unless you really want to do otherwise.

You may compare it to the disussions going on about the interface of
Gimp & Photoshop. Here are some impressions what users do to run Gimp in
1 window:
HOWTO: Run GIMP in its own window. -
http://ubuntuforums.org/showthread.php?t=240543&highlight=gimp+howto

Many huge open source projects have usability commitees or guidelines
beyond the general workflow for the specific application.
Are such issues considered by the development team?

These are considered, though there is not a usability committee because the
development team is relatively small compared with the size of this project.
There is a lot of discussion on this archived on the WIKI, where we went
through a design process before starting in on the new GUI.

Please consider Jarek's concern. We all want to get FOSS4G more
mainstream. I think that Ubuntu is streamlined towards usability and
really easy to use [please, I am not starting a distro flame here!] and

If by mainstream, you mean used by more people, then I think we all agree.
Making GRASS more easily useable will certainly help in that direction.
There are well over 300 commands in GRASS, each with may options. And there
is a lot of additional functionality built into the GUI for managing
visualization and output. Trying to make this complexity both accessible and
less intimidating is a big challenge, but worth the effort.

If, however, you mean by mainstream that it should look like the leading
commercial product, then I disagree. Copying a commercial product just
because it has a good marketing team and has sold a lot of copies doesn't
make for a better piece of software. It is certainly worth looking at what
other software does and does well, but I think we have the opportunity to do
better than commercial products.

Cheers
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

[Tim_Michelsen]

Many huge open source projects have usability commitees or guidelines
beyond the general workflow for the specific application.
Are such issues considered by the development team?

These are considered, though there is not a usability committee because the
development team is relatively small compared with the size of this project.
There is a lot of discussion on this archived on the WIKI, where we went
through a design process before starting in on the new GUI.

Maybe the team could consider to call users for a on their persieved usability when the GUI is to be released. I'll have a look at that wiki page... and come back if there are more suggestions.

If by mainstream, you mean used by more people, then I think we all agree.
Making GRASS more easily useable will certainly help in that direction.

Yes, this was my understanding of mainstream: get more users for GRASS (me included) becuase they are convinced of the well designed workflow and capabilities.

If, however, you mean by mainstream that it should look like the leading
commercial product, then I disagree.

Didn't even think about this option. Although it's very persuasive to draw such a conclusion because some commercial apps are the background where man come from.

Tim

[H_B]

Michael Barton wrote:

That said, it could be convenient to attach/dock a map display to the
layer manager, in order to move them around together. I'm looking into
a way to do that. May or may not be possible.

if this is possible, it would make both camps happy.

another way too gee-whiz eye candy solution is a pop-down semi-
transparent heads-up-display overlay in the display window.

This is not referring to the properties dialogs for each GRASS
command. These are unavoidable if you want to run the command, but can
be closed to clean up the screen. Press OK instead of Apply and the
window goes away. Grouping them into a single MDI wouldn't make them
any easier to work with or less cluttered. Hamish has suggested making
them modal by default, with the option of keeping them open if you
want via a checkbox. This sort of forces you to keep your screen clean
unless you really want to do otherwise.

Ah, I didn't know about [Ok] and [Apply] for the module GUIs. That's a
lot clearer than a "keep alive" checkbox, and obviates the need.
Generally I think that Apply buttons are not that useful, but they could
do a very nice job here.

Hamish

[M_S]

Just a users’s opinion for what it is worth… =D

I really like the GUI setup for GRASS under GIS.M. It is very intuitive and the non-modal windows are awesome. truely lets one multi-task while GRASSing. Great improvement over the previous GUI. that output manager is sweet too! Plus the menus can be undocked. Compariing to it to that other software company that is so prevalent in the US, GRASS is more logically organized (even for those of us across the great blue sea! =D in their “toolbox” there are so many eye-candy widgets that one often finds them self searching for the tool in the “help” because it takes so much time to root throgh the unclearly organized “toolbox”.

GRASS is wonderful. I have been using it for many years now learning and light use. Now that I am using it extensively I have really come to appreciate the rich features, great interface and reliability.

All the developers have really built a great GIS. Keep up the great work. It is enjoyed by many.

Mark

On 6/5/07, Hamish < hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

That said, it could be convenient to attach/dock a map display to the
layer manager, in order to move them around together. I’m looking into
a way to do that. May or may not be possible.

if this is possible, it would make both camps happy.

another way too gee-whiz eye candy solution is a pop-down semi-
transparent heads-up-display overlay in the display window.

This is not referring to the properties dialogs for each GRASS
command. These are unavoidable if you want to run the command, but can
be closed to clean up the screen. Press OK instead of Apply and the
window goes away. Grouping them into a single MDI wouldn’t make them
any easier to work with or less cluttered. Hamish has suggested making
them modal by default, with the option of keeping them open if you
want via a checkbox. This sort of forces you to keep your screen clean
unless you really want to do otherwise.

Ah, I didn’t know about [Ok] and [Apply] for the module GUIs. That’s a
lot clearer than a “keep alive” checkbox, and obviates the need.
Generally I think that Apply buttons are not that useful, but they could
do a very nice job here.

Hamish

---

grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

[Glynn_Clements1]

Michael Barton wrote:

> I think that this is a crucial point.
> There should definately a option to run all Grass sub-windows all in one
> master windows.

An MDI hearkens back to Windows 95 and gets to be a real problem if you want
to have multiple displays open.

I wouldn't suggest using MDI. Being able to [un]dock windows via wxAUI
is the way to go, IMHO.

IOW, whether a panel is its own window or part of another window
should be the user's decision. Forcing one or the other will be the
wrong solution for some proportion of users.

> Maybe others like their screen cluttered but especially newbie for whom
> the new GUI is a *real* improvement will get confused.
> Don't forget that besides Grass users may also use a folder browser,
> terminal and mail application at the same time. And now that Grass is
> being ported to Windows don't forget that Windows doesn't have virtual
> workspaces like Gnome, KDE, etc.!

The basic GRASS application design is a minimum of one display and one layer
manager window. Every new instance (new display) adds only one more window
because the single layer manager works for all displays

Each display needs layer management, which takes up a fixed amount of
horizontal space (due to the width of layer names, on/off checkbox,
icon/button to ID layer type and launch properties dialog). If you
permanently attach a layer management window to each display, every display
window must be that much larger (or the display area of the window that much
smaller). You also waste additional vertical space in the layer manager area
when the display is considerably higher than the layer manager needs to be.
This is often the case unless you have a LOT of layers contributing to a
single display.

If the user has a sufficiently large screen, this isn't a problem.
Again, this should be the user's choice.

--
Glynn Clements <glynn@gclements.plus.com>

[cmbarton]

On 6/5/07 7:00 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

I wouldn't suggest using MDI. Being able to [un]dock windows via wxAUI
is the way to go, IMHO.

This is the route I'm looking into.

Michael

IOW, whether a panel is its own window or part of another window
should be the user's decision. Forcing one or the other will be the
wrong solution for some proportion of users.

__________________________________________
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

[Malte_Halbey-Martin1]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I really like the GUI design of GRASS,

why? Because I can easy use it on two screens (one for the work, one
for the displays), can use many monitors two compare maps, etc.

I see more advantages in the multiple windows GUI and think this is a
unique selling point.

Just my two cents
Malte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZZXGrf7rTyLkTO4RAhhpAKCrmB1kXMye1b2y4Df+rTA0Vf/LzACgpv5L
X8saMYKNT57oFUenfim22so=
=6+Vx
-----END PGP SIGNATURE-----

[Carlos_Guano_Grohman]

I agree. In a single-window environment, you are limited. With
multiple windows, the GRASS way, you have a lot more flexibility.

you can have different maps show side by side (using two displays),
which you can't using a unique window (like Arc), you can leave all
your tools in one window and the map in another, if you have two
screens, and you can have the dialogs for those tools you use more
often (say, r.info, r.mapcalc, etc etc) _opened_ because they are nor
modal, so you don't have to go all through the menus again and again
if you want (need) to do the same task. I just _love_ this.

Also, about the commercial apps, not all of them use the single-window
paradigm. See, for instance ENVI
(http://www.ittvis.com/envi/index.asp) or ERMapper
(http://www.ermapper.com/) which are havy apps (expensive) that use
multiple windows (with ENVI you can get dozens). And no one is
complaining with the companies, because it is good. it works.

Carlos

On 6/5/07, Malte Halbey-Martin <malte@perlomat.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I really like the GUI design of GRASS,

why? Because I can easy use it on two screens (one for the work, one
for the displays), can use many monitors two compare maps, etc.

I see more advantages in the multiple windows GUI and think this is a
unique selling point.

Just my two cents
Malte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZZXGrf7rTyLkTO4RAhhpAKCrmB1kXMye1b2y4Df+rTA0Vf/LzACgpv5L
X8saMYKNT57oFUenfim22so=
=6+Vx
-----END PGP SIGNATURE-----

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Visiting Researcher at Kingston University London - UK
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+
_________________
"Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive."
--The winning entry in a "What were HAL's first words" contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

[Jarek_Jasiewicz1]

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

[cmbarton]

Thanks! We keep trying to make it better. Glad that you think we are succeeding with this.

Michael

On 6/5/07 4:32 AM, “M S” mseibel@gmail.com wrote:

Just a users’s opinion for what it is worth… =D

I really like the GUI setup for GRASS under GIS.M. It is very intuitive and the non-modal windows are awesome. truely lets one multi-task while GRASSing. Great improvement over the previous GUI. that output manager is sweet too! Plus the menus can be undocked. Compariing to it to that other software company that is so prevalent in the US, GRASS is more logically organized (even for those of us across the great blue sea! =D in their “toolbox” there are so many eye-candy widgets that one often finds them self searching for the tool in the “help” because it takes so much time to root throgh the unclearly organized “toolbox”.

GRASS is wonderful. I have been using it for many years now learning and light use. Now that I am using it extensively I have really come to appreciate the rich features, great interface and reliability.

All the developers have really built a great GIS. Keep up the great work. It is enjoyed by many.

Mark

On 6/5/07, Hamish < hamish_nospam@yahoo.com mailto:hamish_nospam@yahoo.com > wrote:

Michael Barton wrote:

That said, it could be convenient to attach/dock a map display to the
layer manager, in order to move them around together. I’m looking into
a way to do that. May or may not be possible.

if this is possible, it would make both camps happy.

another way too gee-whiz eye candy solution is a pop-down semi-
transparent heads-up-display overlay in the display window.

This is not referring to the properties dialogs for each GRASS
command. These are unavoidable if you want to run the command, but can
be closed to clean up the screen. Press OK instead of Apply and the
window goes away. Grouping them into a single MDI wouldn’t make them
any easier to work with or less cluttered. Hamish has suggested making
them modal by default, with the option of keeping them open if you
want via a checkbox. This sort of forces you to keep your screen clean
unless you really want to do otherwise.

Ah, I didn’t know about [Ok] and [Apply] for the module GUIs. That’s a
lot clearer than a “keep alive” checkbox, and obviates the need.
Generally I think that Apply buttons are not that useful, but they could
do a very nice job here.

Hamish

---

grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

---

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

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

[cmbarton]

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

On 6/5/07 11:48 AM, "Jarek Jasiewicz" <jarekj@amu.edu.pl> wrote:

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

[Jarek_Jasiewicz1]

Michael Barton napisał(a):

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

On 6/5/07 11:48 AM, "Jarek Jasiewicz" <jarekj@amu.edu.pl> wrote:

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

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