[GRASSLIST:7692] Re: Interactive GUI input/output

[Glynn Clements]

Paul Kelly wrote:

> > Personally, I'd rather modules which are supposed to be
> > non-interactive (e.g. r.in.gdal) were fixed so that they really were
> > non-interactive. The pervasive assumption that a module can fall back
> > to communicating with the user via a terminal is the biggest issue
> > standing in the way of a decent GUI for GRASS.
> 
> r.in.gdal requires user input if it is creating a new location based on 
> the co-ordinate system associated with an external dataset *and* the 
> datum specified in that co-ordinate system has more than one possible 
> set of transformation parameters. There is no way to automatically 
> determine which set is most appropriate; it depends on several factors, 
> most notably what part of the country the dataset is situated in.

So allow the user to specify it as a command-line parameter, and fail
if it is required but not provided. Ideally, the error message should
enumerate the valid options.

> To make a non-interactive guess or assumption would be lulling the user 
> into a false sense of security and might result in loss of accuracy 
> later if the most appropriate set of datum parameters had not been 
> chosen. IMHO the best way around this is to provide the user with all 
> the information available about the various sets of transformation 
> parameters and let him or her choose the most appropriate set for the 
> area. As there is still no GRASS library for user interaction like this 
> the most foolproof way of doing it remains the traditional interactive 
> terminal approach.
> 
> Hence the problem as outlined previously.
> 
> Perhaps the best thing to do for now (although controversial I'm sure) 
> might be to remove the capability to automatically create a new location 
> from r.in.gdal and v.in.ogr, leaving g.proj as the only module with the 
> capability?

IMHO, creating a new location and importing a raster map are such
fundamentally different operations that they don't belong in the same
binary.

The task of creating a new location should probably be moved to e.g. 
g.newlocation.gdal.

[More generally, there should be g.* commands for managing locations
and mapsets, i.e. creation, deletion, copying, renaming.]

> There could be multiple Tcl/Tk GUI entries for g.proj: one 
> of them could be specifically for creating a new location based on the 
> co-ordinate system associated with an existing external dataset and this 
> could be forced to always spawn a terminal (although it still sometimes 
> wouldn't be needed, e.g. when creating a WGS84 location where there is 
> only one possible set of datum transformation parameters). This 
> functionality should probably also be added to the start-up screen. But 
> I know virtually nothing of the GRASS GUI especially the recent 
> improvements.

One of the main limitations is that it doesn't cope well with programs
which have different "modes", i.e. substantially separate functions
bundled into a single program (although arguably such situations
suggest a design flaw in the program itself).

In particular, if a program has an interactive mode, the only way that
the GUI can handle this is to always launch the program in a terminal.
There's no way that a program can inform the GUI that it is
interactive only for certain combinations of arguments.

This isn't just an issue for the GUI. It applies equally to scripts,
web interfaces etc. Falling back to prompting the user makes life easy
for the programmer, but it can substantially reduce the usefulness of
the program.

-- 
Glynn Clements <glynn at gclements.plus.com>