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

[Markus Metz]

On Fri, Sep 23, 2016 at 1:11 PM, Markus Neteler <neteler at osgeo.org> wrote:
> 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:
> ...
>>> 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,

Your motivation is to provide a specialized CLI interface for HPC
processing? We used GRASS with HPC processing for years and the
problems we faced were causes by the HPC hardware and software
infrastructure, not by GRASS. What exactly is the problem with using
GRASS and HPC processing? You could ask on the GRASS user ML, or a
GRASS developer who has experience with HPC processing.

>
>>> How do we make sure people understand the options were not
>>> removed, but are just hidden?
>
> 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 assume that most GRASS users regard the command line as advanced
usage, therefore the CLI should always show all flags and 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.

See above. Why exactly do you want to change the command line
interface? What is the problem?

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

You wrote "The flags and parameters for advanced users should be
hidden by default", and Anna referred to such advanced options.

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

As you said, your problem is related to HPC processing. Why do you
think more flags and options are a problem for HPC processing?
Particularly for HPC processing, I would assume that the more
information and the more control you have, the better.

Markus M