[GRASS-dev] Adding an expert mode to the parser

[Moritz Lennert]

On 23/09/16 13:11, Markus Neteler wrote:
> On Fri, Sep 23, 2016 at 10:15 AM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at club.worldonline.be>> wrote:
>> On 23/09/16 02:37, Anna Petrášová wrote:
> ...
>>> Probably not so complicated, but I would be more concerned with the
>>> decisions coming with this. For example, what should the online manual
>>> show?
>
> Using the parser, the advanced options could automatically go into a
> subsection of the description part.
> Just to distinguish them easily from the "standard" options.
>
>>> How do we decide which options are advanced.
>
> We simply keep 95% of all as-is.
> But those we need for example for improved HPC processing (yet to be
> added) we may not want to clutter the standard interface with,

No possibility of embedding this into some configuration module (à la 
r.li.setup) which sets the relevant options and then just adding one 
flag to the other modules, e.g. '-h' for 'take into account the HPC 
settings ?


>
>>> How do we make sure people understand the options were not
>>> removed, but are just hidden?
>
> Easy: since they show up in the manual, it is documented.
> Having an "[ ] advanced" button in the GUI, it is obvious.
> For those being on command line, we could either show the advanced
> options, or, if not show instead a hint that this particular command
> also offers advanced options.

I would plead for a separate, but visible 'advanced options' section.


> Example: today d.vect comes with this mount of flags and parameters:
> d.vect --interface-description | grep 'flag name\|parameter name' | wc -l
> 39
>
> In a single line (dirty hack):
>
> for i in `ls -1 bin/* scripts/*` ; do echo -n "$i," ; $i
> --interface-description | grep 'flag name\|parameter name' | wc -l ;
> done | sort -n -t',' -k2
> [...]
> bin/r.watershed,27
> bin/r.sim.water,28
> bin/v.in.ogr,28
> bin/r.gwflow,29
> bin/v.vol.rst,29
> bin/r.solute.transport,32
> bin/v.surf.rst,32
> bin/d.legend,33
> bin/r.sun,34
> bin/d.vect,39
> bin/g.region,40
>
>
> So, would adding 25% of new flags and parameters to many modules in the
> next years still be ok? I guess not. So we need to understand how to
> handle that.
> Hence my proposal to structure them a bit better.

Ok. We might also think about the option of subdividing those modules 
with too many flags into several separate modules sharing the same code 
base. Or go the QGIS way, i.e. create several pre-configured wrapper 
scripts for the most "complicated" modules with several options preset 
and thus not visible in the interface.

But, I see your point and it is definitely necessary to think about the 
options.

Moritz