[GRASS-dev] lib/vask

[Glynn Clements]

Brad Douglas wrote:

> Hello code warriors,
> 
> Yep...Bringing up a long-standing unresolved topic. :-)
> 
> Can we have some discussion about a replacement for lib/vask?  This is
> the library that handles input from the console (used extensively in 5.x
> and is on its way out).
> 
> The "easiest" way to handle it is by passing in parameters via text
> file, but is far from user-friendly.

IMHO, it's probably more user-friendly than using vask. Most text
editors are simpler and more functional than vask forms. There's no
reason why you can't pre-create the text file with the field labels
and (optionally) default values.

The only real advantage of vask is that you can prevent some basic
errors, e.g. entering a value which is too long, entering a value
which isn't a valid integer, etc. Note that the validation is limited
to what is built into vask itself; the application can't perform its
own checks as fields are entered, as the entire input process is
handed off to the vask library until the user indicates completion
using Esc-Enter.

>  Some small portion of this can
> also be resolved by adding options for G_parser().
> 
> In reality, I believe there needs to be something a little more advanced
> that is transparent to whether it is being 'called' from the GUI or CLI.
> I don't pretend to have any decent answers (I've never had to code for
> both before), but maybe the group of us can come up with something
> that's easy for users and developers alike to use without the pitfalls
> of the current implementation.
> 
> Searching the archive, I see a fair amount of discussion about why not
> to use V_*() functions, but no long-term solutions.
> 
> This is holding up many modules being ported to 6.x and I suspect it
> will have impact on the GUI projects currently in development.  I'd also
> like to develop some module(s) for handling metadata, but I cannot
> continue until I have some direction as to handling input/editing,
> globally.
> 
> Suggestions?

First, let's look at what actually uses it:

grass=> SELECT DISTINCT object FROM obj_imp WHERE symbol ~ '^V_' ;
                                 object                                  
-------------------------------------------------------------------------
 imagery/i.ortho.photo/photo.camera/OBJ.i686-pc-linux-gnu/mod_cam_info.o
 imagery/i.ortho.photo/photo.elev/OBJ.i686-pc-linux-gnu/ask_elev.o
 imagery/i.ortho.photo/photo.elev/OBJ.i686-pc-linux-gnu/mod_elev.o
 imagery/i.ortho.photo/photo.init/OBJ.i686-pc-linux-gnu/mod_info.o
 imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_elev.o
 imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_files.o
 imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_files2.o
 imagery/i.ortho.photo/photo.rectify/OBJ.i686-pc-linux-gnu/ask_wind.o
 imagery/i.ortho.photo/photo.target/OBJ.i686-pc-linux-gnu/ask_target.o
 lib/edit/OBJ.i686-pc-linux-gnu/edit_cats.o
 lib/edit/OBJ.i686-pc-linux-gnu/edit_cellhd.o
 lib/edit/OBJ.i686-pc-linux-gnu/edit_hist.o
 lib/imagery/OBJ.i686-pc-linux-gnu/ask_bands.o
 lib/imagery/OBJ.i686-pc-linux-gnu/ask_colors.o
 lib/imagery/OBJ.i686-pc-linux-gnu/tape_info.o
 lib/imagery/OBJ.i686-pc-linux-gnu/v_exec.o
 lib/imagery/OBJ.i686-pc-linux-gnu/vask_group.o
 lib/init/OBJ.i686-pc-linux-gnu/set_data.o
 lib/vask/OBJ.i686-pc-linux-gnu/V_acc.o
 lib/vask/OBJ.i686-pc-linux-gnu/V_call.o
 lib/vask/OBJ.i686-pc-linux-gnu/V_clear.o
 lib/vask/OBJ.i686-pc-linux-gnu/V_const.o
 lib/vask/OBJ.i686-pc-linux-gnu/V_line.o
 lib/vask/OBJ.i686-pc-linux-gnu/V_ques.o
 raster/r.le/r.le.setup/OBJ.i686-pc-linux-gnu/ask_group.o
 raster/r.support/modhead/OBJ.i686-pc-linux-gnu/ask_format.o
 vector/v.transform/OBJ.i686-pc-linux-gnu/ask_trans.o
(27 rows)

IOW:
	i.orpho.photo
	r.le.setup
	v.transform
	etc/set_data
	etc/support/modhead
	lib/edit
	lib/imagery

Michael is already working on a v.transform replacement.

Both gis_set.tcl and the option of specifying the mapset directory on
the command line are available as alternatives to etc/set_data.

The etc/support/modhead program only uses it directly if you want to
change the format details for the [f]cell file, which should only be
necessary if the file is somehow broken (if it isn't, changing any of
those parameters will break it). There's no reason that can't be done
with a command-line module; the more useful feature of changing a
map's boundaries or resolution can already be done using r.region.

r.le.setup uses it for a single form which obtains 9 parameters; this
could be done with either a command-line tool or by editing a text
file.

lib/edit provides options to edit the cellhd, cats or history for a
map. This is used by set_data and etc/support/mod{head,cats,hist}
only. All of these could be implemented via editing a text file.

As for the parts of lib/imagery which use it:

grass=> SELECT * FROM obj_imp WHERE symbol ~ '^I_v?ask' ;
                             object                              |          symbol          
-----------------------------------------------------------------+--------------------------
 imagery/i.class/OBJ.i686-pc-linux-gnu/ask_files.o               | I_ask_signature_file_any
 imagery/i.class/OBJ.i686-pc-linux-gnu/ask_files.o               | I_ask_signature_file_old
 imagery/i.class/OBJ.i686-pc-linux-gnu/ask_files.o               | I_vask_subgroup_old
 imagery/i.ortho.photo/menu/OBJ.i686-pc-linux-gnu/menu.o         | I_ask_group_old
 imagery/i.ortho.photo/photo.camera/OBJ.i686-pc-linux-gnu/main.o | I_ask_camera_any
 imagery/i.points/OBJ.i686-pc-linux-gnu/main.o                   | I_ask_group_old
 imagery/i.vpoints/OBJ.i686-pc-linux-gnu/main.o                  | I_ask_group_old
 lib/imagery/OBJ.i686-pc-linux-gnu/ask_bands.o                   | I_ask_group_any
(8 rows)

Again, i.[v]points should be made redundant by Michael's current
project.

i.orpho.photo is one of those "applications" for which the only
sensible solution is a complete rewrite (or complete disposal; how
important is it?). Actually, that applies in large measure to the
whole "imagery" subsystem.

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