[GRASS5] New gui.tcl generic user interface

[Cedric Shock]

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