[GRASS-dev] Need to update g.setproj

[Michael Barton]

Paul,

Thanks for the informative comments. I have a couple of contributions below.

Michael
__________________________________________
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


> 
> Well yes what I was proposing was that interactive use need not require an
> interactive terminal window, if we create some functions that abstract the
> interactive prompting from the module so it doesn't care whether it is
> being run from the command-line user interface or a graphical user
> interface; all it does is let the user know what options are available and
> receive the user's response.

>From my admittedly limited experience with GUI development (TclTk and
wxPython), a module that insists on sending a message and expecting a user
response--by whatever means--is very problematic to use in a GUI. The GUI is
designed to handle all user interaction. Having the module "intrude" in this
way is either hard to program around or makes it unusable.

> 
>> What I suggest is simply that the module fail with a meaningful error
>> message (e.g. "You must enter a datum transformation for this projection")
>> if the proper combination of parameters are not set in the end. It is fairly
>> straightforward to do the interactive part in a GUI platform like TclTk or
>> wxPython. Users would be prompted for different options depending on which
>> other options they chose. That is, different options would be presented for
>> wgs84 UTM than for NAD83.
> 
> That just doesn't seem elegant to me. E.g. suppose somebody wanted to
> write a different GUI to call g.proj (there are several GRASS GUIs about)
> then all this interactive prompting functionality would have to be
> re-implemented in that GUI too. E.g. in GRASS already g.proj is called
> both from the start-up screen and gis.m I guess.

Yes, each GUI needs to use its own widgets and functions. But requiring user
interaction at the module level does not make this any easier. On the
contrary, if it is a straightforward command with option=value pairs, it
will be easier to drop into a different GUI platform than if you have to
also come up with a way to receive and parse input from the module. Also,
current GUI's tend not to follow the prompt and respond model.

> 
>> To do this, however, it must be completely runable from the command line,
>> with no interaction required. This takes considerable burden of the
>> underlying C module. Don't worry about dropping the xterm interaction that
>> is already there. People can continue to use it if desired. We just need an
>> alternative mode that does not require it. The latter could be turned on and
>> off by a flag, for example.
> 
> But the interactive prompting and converting of user input forms the vast
> bulk of what g.setproj does.

This is why I'm hoping a non-interactive behavior is pretty easy to
implement.

> Really what you are proposing is duplicating
> this functionality in a new Tcl/Tk module.

Exactly

> I just thought it would be nice
> (to avoid code repetition, easy to fix bugs etc.) if the command-line
> interactive and GUI interactive versions of a module could be combined in
> one place using (as yet non-existent) interactive input functions
> abstracted from the user interface.

It would be nice in theory, but doesn't work this way, at least with the
platforms that we're using for GRASS and that I'm familiar with.

Michael