module GUIs: "or enter values interactively" should be opt-in

[hamish]

Hi,

for the G_standard_input for input files, the auto-generated wx module GUIs are always asking "or enter values interactively" whenever G_define_standard_option(G_OPT_F_INPUT) is present.

Since that makes no sense for binary input files, and anything automatic should err on the side of not being weird, the interactive version should be opt-in -- the programmer should have to use a special gisprompt in those cases. (e.g. r.in.gdal, v.in.ogr, r.in.bin (G6.x), r.in.mat, ...)

fwiw section 12.16.5.2.4 of the grass5 programmer's manual has a full description of what the a,b,c options of gisprompt were originally designed to be,

12.16.5.2.4 gisprompt Member

The gisprompt Option structure item requires a bit more description. The
three comma-separated (no spaces allowed) sub-arguments are defned as
follows:

First argument:
"old" results in a call to the GRASS library subroutine G_ask_old, "new"
to G_ask_new, "any" to G_ask_any, and "mapset" to G_ask_in_mapset.

Second argument:
This is identical to the "element" argument in the above subroutine
calls. It specifes a directory inside the mapset that may contain the
user's response.

Third argument:
Identical to the "prompt" argument in the above subroutine calls. This is
a string presented to the user that describes the type of data element
being requested.

see lib/gis/ask.c for the "above subroutine calls".

I first considered to mangling all the gisprompts by hand to stop the "interactive" text box but keep the Browse button, but then it occurs to me that the gui parser is the problem, not the modules. (also it seems the above a,b,c have been continually redefined since the tcltk gui days, so we should better sort out what it means now if gisprompt is to be different in grass7)

thanks, Hamish

[glynn]

Replying to hamish:

(also it seems the above a,b,c have been continually redefined since the tcltk gui days, so we should better sort out what it means now if gisprompt is to be different in grass7)

GRASS 7 no longer has any of the "ask" functions.

The first component (age) is used within the parser in relation to overwrite checks. If the age component is "new" and overwrite isn't enabled, then the second component (element) is used to determine whether the specified entity already exists.

Also, G__uses_new_gisprompt() returns true if any option has an age of "new"; this causes the the --overwrite option to be listed as a recognised flag in the output for --help etc.

The third component (prompt) is no longer used directly by libgis, although it may be used by the GUI.

[hamish]

If term 2 (element) is "file", trunk's libgis checks to see if the file already exists & insists on --overwrite. So for file input= and output= term 2 should probably stay as "file". This also means that the GUI should use term 2 (element) to decide if there should be a file [Browse] button present, instead of term 3 (prompt/description) as it does now.

term 1 remains "old", "new"; the value of "any" doesn't seem to be used any more in g6.4+ or g7.

so that leaves the switch for deciding on a text input box to be based on the third term (prompt/description). (as far as gui/wxpython/gui_core/forms.py is concerned)

so e.g. for r.in.mat we have this info from --interface-description

<gisprompt age="old" element="mat" prompt="file" />

element would go back to "file", and term 3, prompt (aka description), would change from "file" to "text" (or "bin" or generic "file").

And the "or enter text interactively" box would be made to only show up if prompt was "text".

In GRASS 6 with GRASS_UI_TERM set, the prompt term 3 is used in the "Enter the name of" line, as is term 1's "new". e.g. for r.in.bin it is {input}:

OPTION:   Binary raster file to be imported
     key: input
required: YES

Enter the name of an existing {input} file
Hit RETURN to cancel request
>

so having that be "text" or "binary" would still read well (although still locked to English).

thoughts?

Hamish

[annakrat]

Replying to hamish:

If term 2 (element) is "file", trunk's libgis checks to see if the file already exists & insists on --overwrite. So for file input= and output= term 2 should probably stay as "file". This also means that the GUI should use term 2 (element) to decide if there should be a file [Browse] button present, instead of term 3 (prompt/description) as it does now.

so that leaves the switch for deciding on a text input box to be based on the third term (prompt/description). (as far as gui/wxpython/gui_core/forms.py is concerned)

so e.g. for r.in.mat we have this info from --interface-description

<gisprompt age="old" element="mat" prompt="file" />

element would go back to "file", and term 3, prompt (aka description), would change from "file" to "text" (or "bin" or generic "file").

And the "or enter text interactively" box would be made to only show up if prompt was "text".

I agree. "file" as element and "text" or "bin" as prompt (this is what you mean, is it?). Currently it's the opposite way. Apart from "bin", grep shows also "camera" or "font" - is there any reason to keep them?

[mmetz]

Replying to annakrat: Apart from "bin", grep shows also "camera" or "font" - is there any reason to keep them?

Regarding "camera", please keep it as an element (as in g.findfile element=camera), it is used by the orthorectification modules.

[hamish]

(just to clarify for anyone reading along at home, "element" here typically refers to a subdirectory of the MAPSET dir)