On Fri, Sep 23, 2016 at 10:15 AM, Moritz Lennert < mlenn...@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
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev