[GRASS-dev] module header definitions add: text/multiline and latex support?

Anna Petrášová kratochanna at gmail.com
Wed Jan 14 10:18:12 PST 2015

On Wed, Jan 14, 2015 at 1:07 PM, Nikos Alexandris <nik at nikosalexandris.net>

> Moritz:
>  I personally am not in favour of such additional text in the module. I
>>> think
>>> it would clutter the interface. There is a reason there are man pages
>>> and we
>>> should not encourage users to skip them...
> Pietro:
>  Why? I don't see the reason why we should educate the users...
>> I provide a tool to user that know what they are doing, I want only to
>> make the meaning of the options clearer and self explanatory.
> I share this idea: the GUI should offer an overview at a glance, as simple
> and compact, yet complete as possible.

well, we are still talking about autogenerated dialogs, so you can't expect
a miracle. I agree we should try to reflect the option relations, I just
didn't have time to look at it, besides it's still a very new feature in
parser. I don't expect it to be super simple to implement considering all
the different options and relations.

Regarding the explanatory text, that would have to be implemented in the
parser I guess. The latex part sounds unrealistic (or at least
overcomplicated) in terms of wxPython.

>  Also, how would you integrate that into the command line --help output ?
>>> It
>>> probably wouldn't be as readable and and I'm even more strongly opposed
>>> to
>>> introducing differences in information delivered between the command line
>>> and the GUI.
>> I would not integrate that information in the --help output, but only
>> on the manual page (to avoid repetitions).
>> Command line and GUI are different things with different scope I see
>> no point to have them as a clone.
>  They have different user audience and should be differentiate (imho).
>> For me the module GUI as it is is useless and this is why I just use
>> the command line I don't see any advantage on GUI as it is. I think
>> that make the GUI more clearer could add some value and user don't
>> have to rely on the manual for every single option. The basic info are
>> provided in the GUI and you can find these and further
>> details/material in the manual, e.g. examples, images, etc.
> While I don't think that GRASS' GUIs, as of now, are useless, I understand
> Pietro's view and think similarly.  These questions always appear when you
> try to introduce GRASS in someone without prior experience.  Just try to do
> it, and let him/her tell you what they think.
> Nikos
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150114/5004fa4d/attachment.html>

More information about the grass-dev mailing list