<div dir="ltr">On Fri, Sep 23, 2016 at 10:15 AM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>> On 23/09/16 02:37, Anna Petrášová wrote:<br>...<br>>> Probably not so complicated, but I would be more concerned with the<br>>> decisions coming with this. For example, what should the online manual<br>>> show?<br><br>Using the parser, the advanced options could automatically go into a subsection of the description part.<br>Just to distinguish them easily from the "standard" options.<br><br>>> How do we decide which options are advanced.<br><br>We simply keep 95% of all as-is.<br>But those we need for example for improved HPC processing (yet to be added) we may not want to clutter the standard interface with,<br><br><br>>> How do we make sure people understand the options were not<br>>> removed, but are just hidden?<br><br>Easy: since they show up in the manual, it is documented.<br>Having an "[ ] advanced" button in the GUI, it is obvious.<br>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.<br><br>>> If the goal of this is to simplify life for new users, we can focus<br>>> the efforts on GUI.<br><br>Yes, that's easy. But I am indeed thinking about the command line here.<br><br>>> If we tag an option as advanced in parser, it<br>>> could be moved to a special tab 'Advanced', which some modules already<br>>> have.<br><br>Yes.<br><br>>> I am not sure hiding the options completely is a good idea.<br><br>This is not what I intended (nor wrote I think).<br><br>>> Also in manual pages, perhaps these advanced options could somehow be<br>>> visibly marked as advanced (or possibly hidden with some javascript?).<br><br>Exactly.<br><br>> If any, I would say +1 for Anna's suggestion. I don't really like the idea<br>> of "hiding" options behind an environment variable.<br><br>It is not about hiding, as I just tried to explain maybe better now.<br>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.<br><br>> This said, I haven't really experienced that many problems with complexity<br>> of modules with newbies. Yes, some are a bit overwhelmed at first contact,<br>> but with a little guidance they quickly get the hang of things...<br><br>But extrapolating from the '90th, we tend to add more and more..<br><br>Example: today d.vect comes with this mount of flags and parameters:<br><span style="font-family:monospace,monospace">d.vect --interface-description | grep 'flag name\|parameter name' | wc -l<br>39</span><br><br>In a single line (dirty hack):<br><br><span style="font-family:monospace,monospace">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<br>[...]<br>bin/r.watershed,27<br>bin/r.sim.water,28<br>bin/v.in.ogr,28<br>bin/r.gwflow,29<br>bin/v.vol.rst,29<br>bin/r.solute.transport,32<br>bin/v.surf.rst,32<br>bin/d.legend,33<br>bin/r.sun,34<br>bin/d.vect,39<br>bin/g.region,40</span><br><br><br>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.<br>Hence my proposal to structure them a bit better.<br><br>cheers,<br>Markus<br></div>