[GRASS-dev] r45050: v.info: -r/-m/-t -> shell param; GEM; parser.c

[Martin Landa]

Hi,

2011/1/17 Hamish <hamish_b at yahoo.com>:
> re. https://trac.osgeo.org/grass/changeset/45050
>
> grass has certain conventions it uses through many modules. having
> all modules work the same way (or near to it) makes it much easier
> to pick up new modules and have them work as expected, which
> makes grass's reputedly harsh learning curve less so. what's the
> justification for introducing non-standard behavior into v.info?

are you referring to GRASS6? If so, why don't change some "standard"
or "conventions" in GRASS7? ;-)

I remember discussion about number of flags of g.region. There was
suggestion to reduce number of flags as I have done for v.info. The
CLI follows clear design (group related flags to the one option). In
the case of v.info -r/-m(and new -g) to `shell=basic,region,topo`. GUI
is also much more intuitive in the result (try it out). Same can be
done for g.region, which ended up with extremely large number of
flags. The goal is not to break conventions, just to make interface of
GRASS modules more intuitive for the end-user. Of course it's question
for discussion.

> (messing up the modules' CLIs to improve GUI cosmetics makes me
> rather grumpy..)

In which way the CLI of v.info has been messed up?

> also, re. https://trac.osgeo.org/grass/changeset/45039,
> is GEM fundamentally broken on WinGrass or is it buggy or just
> a personal decision to disable that lesser used feature?
>
> Mostly I just ask please discuss these things with the list
> first. Especially for anything that touches parser.c* and the
> core Makefile in the release branch during RC.

gcc -g -Wall -pedantic -Werror-implicit-function-declaration
-fno-common  -o tools.o -c tools.c
tools.c: In function `dump_plain':
tools.c:572: error: implicit declaration of function `mkstemp'
make: *** [tools.o] Error 1

Probably gnulib is needed. No time to fix it (and no interest), nobody
has fixed during the last year(s). Who is using GEM?

> [*] even though I'm overjoyed to see "--help" finally parsed in
> the dev branches
>
>
> somewhat related, I object to this change:
>
> r44435 releasebranch_6_4/lib/gis/parser.c:
>  call G_usage() when level is verbose (merge r44433 from trunk)
>
> it you got the usage wrong, and you didn't use --quiet, the
> obvious thing you'll do next is to look up the correct one...
> --verbose to get at it is not obvious, so you waste time finding
> the right manual. theoretically the GUIs should never get the
> usage wrong as they get it from the --interface-description.

OK, you are right that calling G_usage() should not be related the
verbosity level. I was always embarrassed with G_usage().

$ r.info input=x --v
Sorry, <input> is not a valid parameter
ERROR: Required parameter <map> not set:
        (Name of raster map)

Description:
 Output basic information about a raster map layer.

Keywords:
 raster, metadata

Usage:
 r.info [-rstghudmp] map=name [--verbose] [--quiet]

Flags:
  -r   Print range only
  -s   Print raster map resolution (NS-res, EW-res) only
  -t   Print raster map type only
  -g   Print map region only
  -h   Print raster history instead of info
  -u   Print raster map data units only
  -d   Print raster map vertical datum only
  -m   Print map title only
  -p   Print raster map timestamp (day.month.year hour:minute:seconds) only
 --v   Verbose module output
 --q   Quiet module output

Parameters:
  map   Name of raster map

You need to scroll up to find out what is wrong. Extremely annoying.
Now it ends up with clear message

$ r.info input=x
Sorry, <input> is not a valid parameter
ERROR: Required parameter <map> not set:
        (Name of raster map)

You get clear info what is wrong. Probably the user could be inform
how to get the usage info. Something like

For module's syntax information call `r.info --help`.

Hm, about the GUI, what about launching commands from Layer Manager
command line? Easy to make a mistake.

> and fwiw this one I think makes things more confusing, as it
> implies `dirname` (vs `basename`), when the correct usage is
> like [/path/to/]filename.ext.
>  https://trac.osgeo.org/grass/changeset/44339/grass/branches/releasebranch_6_4/lib/gis/parser.c

Sorry I don't understand, this parameter takes path to the file
(relative or absolute)...

Martin

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa