On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo <veroand...@gmail.com> wrote:
> I'm with MaDi in that if I see a very long list of flags and parameters in > the terminal when using --h, i just go to the manual... I just use --h in > CLI for a quick recalling of flags/options... A reduced list of most > commonly used flags would be nice, but still keep the possibility to get > the advanced flags/parameters as well, if the user needs more info... > If the --help is just for scanning and the issue is that it simply too long, hiding some parameters is not the only option we have. For many (and more in the future hopefully) parameters we have (short) label and (longer) description. --help prints both (if both are present, that's at least 2 lines per parameter). Additionally, if the option has predefined values which have descriptions, there is one line for each of those. So, the question is would it be helpful (at least as a first step) if --help would print less information for each parameter but still provided all parameters? > and the same in the GUI > In the case of GUI, we should first answer the question why are the sections/tabs not enough? Because they already should separate basic and advanced while providing actually much finer and partially self-documenting way (for example, you fill in Required tab, go also to Selection, but leave aside Transformation and Advanced tabs). > and manual pages then (a tab or section for advanced flags/parameters)... > > Considering that we have currently as system of (gui) sections which place the options to individual tabs in GUI, isn't showing the different sections in the manual the right thing to do? This would not only make the manual more organized, but it would also link the manual more to the GUI. Depending how good and smart are we with the styling and JavaScript we can even hide some by default. But perhaps there is a reason why this is not enough. > IMHO, a major issue however is the lack of examples for the usage of more > advanced flags or options (or even the required and more common ones). Take > the case of several i.* modules, for example... but maybe this should go in > a separate thread :-) > Good point. If you have an explanation and example for a flag, perhaps you can understand it and it is not so advanced at the end.
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev