On 23/09/16 13:11, Markus Neteler wrote:
On Fri, Sep 23, 2016 at 10:15 AM, Moritz Lennert
<mlenn...@club.worldonline.be <mailto: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,
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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
