[GRASS5] New gui.tcl generic user interface

Cedric Shock cedricgrass at shockfamily.net
Thu Mar 16 11:05:52 EST 2006


Michael,

I've been working on other stuff because it's the end of the term here, and I 
haven't gotten a key activated and an id for CVS write access yet.

>
> I'd like to somehow collaborate with you on somehow better merging what you
> are doing and the GIS Manager option panes. The latter are all hard coded.
> I've long realized that this is inefficient, but until now didn't have much
> in the way of an alternative. With the GUI output you've proposed, it
> should be possible to capture the option settings from your new dialogs and
> reroute them into the GIS Manager as appropriate. This will take some hefty
> recoding to start with. After that, however, it should make things MUCH
> easier.
>

I'm not quite sure what you mean here, at all.

Do you mean you want to get automatically generated layouts of options for 
things like the display of vectors? Provided by gui.tcl? If so we'd need to 
radically expand the language of struct Option (to be consistent) to allow 
for selections that influence other selections, like yours do (column 
selection). This would be a good thing in my opinion, but also some hefty 
coding. Perhaps we could change gis prompt options to:

new/old,element or class,Window Text,[optional] parent

And then have, for example:

key: boundaries
gisprompt: old,vector,Select Input Boundaries
...
key: layer
gisprompt: old,vector-layer,Select Layer,boundaries
...
key: columns
multiple: yes
gisprompt: old,vector-layer,Select Columns,layer

If so we'd need to patch everything else that reads from gisprompt. (console 
UI, anything else?)

We'd need to agree on an interface for getting and setting commands and 
possibly individual options (I have one already in unsubmitted stuff).

You would have to source gui.tcl into your program directly for these panes 
(You run it in a separate wish for external command right now, right?)

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

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.

--Cedric




More information about the grass-dev mailing list