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

[Markus Neteler]

On Fri, Sep 23, 2016 at 10:15 AM, Moritz Lennert <
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,


>> 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.

>> If the goal of this is to simplify life for new users, we can focus
>> the efforts on GUI.

Yes, that's easy. But I am indeed thinking about the command line here.

>> If we tag an option as advanced in parser, it
>> could be moved to a special tab 'Advanced', which some modules already
>> have.

Yes.

>> I am not sure hiding the options completely is a good idea.

This is not what I intended (nor wrote I think).

>> Also in manual pages, perhaps these advanced options could somehow be
>> visibly marked as advanced (or possibly hidden with some javascript?).

Exactly.

> If any, I would say +1 for Anna's suggestion. I don't really like the idea
> of "hiding" options behind an environment variable.

It is not about hiding, as I just tried to explain maybe better now.
It is about not adding so many more flags and parameters to the standard
interface, or, a way how to address this upcoming problem for the near
future.

> This said, I haven't really experienced that many problems with complexity
> of modules with newbies. Yes, some are a bit overwhelmed at first contact,
> but with a little guidance they quickly get the hang of things...

But extrapolating from the '90th, we tend to add more and more..

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.

cheers,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160923/0ab8a762/attachment.html>