[GRASS5] New gui.tcl generic user interface

[Michael Barton]

Cedric, Glynn et al.

Here are some first reactions.

My first thought was that, instead of me having to change the hand-coded
options pane every time an option changes, I could just launch your nice new
module, get the option values from there, and use them in the GIS Manager
display. But you folks are right, there is a lot more flexibility in the
hand-coded panes than in the generic ones. And there are only a handful of
display modules that need to be coded in this way.

Several nice and exciting things are happing with the GRASS UI: much better
generic modules for launching commands, NVIZ working in TclTk 8.4, new NVIZ
functionality. So this is a good time to try to coordinate on these various
and welcome improvements in a couple of ways.

1. Maintaining a consistent look/function across different parts of the
GRASS UI. Cedric, your use of the same icons used in the GIS Manager makes
it much easier for users to operate diverse GRASS modules and displays. It
will also make it easier for people to use the GIS Manager. Can we move
toward the same kind of consistency in NVIZ? There are some other places for
consistency. 

I changed TclTk entry widgets to white to signal that the user needs to
enter something there. I did the same for the output text widgets. You might
want to do the same.

I'd also changed the title of the option pane to blue--again to signal that
it is a title. Yours look very nice in black however. What do you all think?
Should we change the module titles to a different color (blue or something
other than black) or my option pane titles back to black?

Benjamin Ducke suggested adding a notebook widget to complex option panes to
help organize them. I don't really need a separate tab for output from the
GIS Manager, but tabs for organization might help. This probably only really
applies to vector panels (including chart and thematic). Any thoughts? Tabs
might be very helpful in NVIZ.

2. Using the same resources. Icons are the most obvious one at the moment.
We should put them all in the same place and all GUI components using them
could then get at them. I saw mention of $GISBASE/etc/icons Cedric. This
seems OK with me. Crishan and Glynn, if we shifted to QT, GTK, or another
GUI platform, would these also use GIF icons? Could they still be kept in
$GISBASE/etc/icons?

3. Consistent functionality. For example, I don't think that module output
should go to the output window at this  time. The reason is that some people
would rather work without the GIS Manager. If all output goes to the output
pane, then the GIS Manager would always need to be launched. In the long
run, however, it does seem to be a good idea to have all command output go
to the same place, so people would always know where to look for it.

Also, if you can tell me how to bind the mouse wheel to widget scrollbars, I
will implement it in the GIS Manager option panes too.

4. Finally, we all might want to look at the UI roadmap on the GRASS WIKI
again. This is not set in stone, but should serve as a guide (an evolving
one) to moving to the next generation UI in a coordinated fashion. Along
these lines, Trevor proposed some nice ideas on how to implement some of the
roadmap ideas. Some echo some of the design ideas that Crishan proposed a
couple months back. (Could you put this on the WIKI in the UI section?).
This would involve adding a tabbed notebook to the GIS Manager so that it
could serve increasingly as a tool box for launching GRASS modules--rather
than only having them launched from (sometimes deeply hierarchical) menus.
The new generic module GUI's fit very nicely into this scheme.

To close, here are some other ideas that I've been thinking about for
continued updates to the UI.

1) using r.profile and TclTk charts to create a new terrain profile utility
that would replace d.profile, produce postscript text and graphics, and not
need x11.

2) creating a text layer that could read label files created by v.label.
This way, we could have high quality, postscript vector labeling.

3) rewriting the GRASS startup GUI. I realized in teaching it this Spring,
that it is much more intimidating than it needs to be. I've looked at the
code and it's ancient. I finally decided that it would probably be easier to
start fresh than to try and update the existing code. Unfortunately, I seem
to have lost what I'd done so far when my laptop went in for repair this
past week (I can't find it on my backup). The basic concept is that the user
needs to identify an existing GIS Mapset to start GRASS. This is a very
simple screen with clear help text. By identifying a mapset, the location
and default directory (GISDBASE) are implied. If there is no pre-existing
mapset available for use, the user is prompted to make a new one. This would
get a new window. And so one. There is more to think about here. But the
main thing is that I believe that starting GRASS can be much less
intimidating than it is.

4) Continuing to debug the GIS Manager so that it can become the default GUI
soon. There are several small tweaks I'd like to make. But the main issue
right now are strange results from compositing with g.pnmcomp. I have no
idea what's causing these. Cedric, since you appear to know both TclTk and C
pretty well, I'd like to ask if you can help us sort this out?

I'm open to suggestion from you folks too.

Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

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



> From: Cedric Shock <cedricgrass at shockfamily.net>
> Date: Thu, 16 Mar 2006 13:08:39 -0800
> To: <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] New gui.tcl generic user interface
> 
> Glynn and Michael,
> 
>> Both d.m and gis.m source gui.tcl. This is why parser.c has both
>> G_gui() and G_tcltk(). The former is for the stand-alone UI and the
>> latter for use by Tcl/Tk programs such as d.m and gis.m.
> 
> Great, then we won't have to worry about namespace collisions, except with the
> few new procs I added gui.tcl.
> 
>> 
>> Having the Tcl/Tk code executed within the context of the main GUI
>> allows for things like command history.
>> 
>>> Do you want the output from commands run in gui.tcl to come through to
>>> your output windows? We'd need an interface for that, and hooking into
>>> stuff. We'd also need to have a way of not getting those buttons (Run,
>>> Help, etc). Perhaps separation of this little bitty UI from the code for
>>> making options frames (libgui.tcl anyone?)
>> 
>> gui.tcl was designed to allow for the possibility of overriding some
>> of its procedures. It shouldn't be necessary to split it up.
> 
> Ok, so we'll dispatch stuff by overriding procs. (Some part of my brain
> thought that was an error in TCL; it isn't). It'd be wise, then, to make sure
> we know exactly what the interface between d.m and gis.m and gui.tcl is going
> to be. I know that how it was written before my changes, and even my first
> revision, it could NOT be used to embed in a frame (without overloading
> begin_dialog, which would be silly).
> 
> I suggest we take the following actions:
> 
> 1. Heavily document gui.tcl OUTSIDE of gui.tcl (I had to do quite a bit of
> this to figure out how to make small, effective changes to gui.tcl).
> 
> 2. Collect a list of all the ways gui.tcl is currently being used andwhat
> procedures are being overridden.
> 
> 2. Propose extensions to the interface, and decide on small modifications to
> make to divide up the work in a simple manner. Both for starting dialogs and
> for this new idea I introduced, of a layout rule. My layout does three
> different things, currently only one is easily factorable:
> 
> It sets up a notebook (this shouldn't be required)
> It puts the output text window somewhere (should be generalized to windows)
> It provides get_frame {dlg guisection} which provides frames for add_option
> and add_flag to pack options and flags into.
> 
> So a layout rule should also implement something like make_layout {dlg, path}
> which does the initial setup and packing in my case making the notebook.
> get_frame should be renamed layout_get_freame. We should also have something
> like layout_get_special_frame {dlg specialguisection} which would give out
> frames for addins(like output). layout_get_special_frame should bind destroy
> on its frame to any cleanup actions necessary (like removing a tab from the
> notebook).
> 
> Then we can change begin_dialog so it does something along the line of the
> following:
> 
> begin_dialog:
> Set up all the module variables, etc.
> make_module_description
> make_layout
> make_command_label
> make_progress
> make_buttons
> return the dialog's id
> 
> Then overridding any of make_module_description, make_command_label,
> make_progress or make_buttons with an empty proc would cause them to not
> happen.
> 
> We'd also need an interface to getting and setting command options, both all
> at once and one at a time. I've already done this. we could call these procs:
> 
> dialog_get_answer and dialog_set_answer for individual options
> dialog_get_command and dialog_set_command for the whole thing at once.
> 
> 3. We also need to agree on who "owns" which of the opt global variables.
> 
>> 
>>> Your hand/hard-coded UIs are in may ways more flexible than what can be
>>> done with a simple layout rule, however consistany of layout does have
>>> its advantages.
>> 
>> I think that hand-coding the layer panels is the way to go. Although
>> for the generic "command" layers, it would be useful (and probably not
>> too hard) to provide a facility to choose a command from a list and
>> bring up the command's auto-generated dialog.
> 
> I think hand-coding is the way to go for carefully designed user interfaces.
> However if we could have the generic user interface be as wonderful as the
> hand coded ones it would be worth persuing.
> 
> My complete lack of ability for automated version control is crippling. If
> anyone knows an easy way to check sources out of a remote repository and
> check the same directories into another repository, and then be able to
> update from the first and commit to the second again that knowledge would be
> extremely helpful to me. It ought be easy to do since making a development
> branch of a remote repository seems like a common need (i.e. everyone without
> write access, or for developing radical new features outside the main
> repository).
> 
> --Cedric Shock 
> 
> 
>