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

[Michael Barton]

Thanks for the ideas Hamish


On 6/4/07 2:56 AM, "Hamish" <hamish_nospam at 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