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

[Paulo van Breugel]

On Wed, Jan 14, 2015 at 5:27 PM, Pietro <peter.zamb at gmail.com> wrote:

> On Wed, Jan 14, 2015 at 3:59 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
> > Can this have a description? I'm not sure where we would show it but it
> > might be useful.
>
> I did a naive mockup showing two options with OR relationship.
>

These text elements could help to unclutter the interface if used properly.
Like the example provided by Pietro, they could for example help to group
the inputs from which the user need to select one (grouping of options
using tabs is another option, but not always a good one). Yes, from the
manual page the user can find out he/she needs to select one, but I am
convinced that for many it would be beneficial if it also is clear at one
glance from the interface.. similar to how the red asterisk helps the user
to see at one glance which parameters are obligatory.


> > However, I'm against introducing some general inter-option
> > info, I'm not sure how it would work in code, GUI, command line and
> manual
> > page. You can always include this information into description of
> individual
> > options.


That works well for one option, but what if you have information that is
relevant to two different options.


> Details can go to a manual page which is accessible from GUI, using
> > man or in web browser.
> >
> > I don't see how you would like the GUI to look like. So if you have some
> > ideas or examples, please share. I can see what Moritz is saying, GUI
> should
> > be the same as command line because they are two interfaces to the same
> > thing.
>

They both provide an interface to the same function, sure, but the
important part here is that they are two different interfaces. Presumably
for a reason, such as different users, different use cases. So for me it
seems perfectly reasonable that there are differences in the level of
information provided (of course there might be very good reasons from a
developer point of view).

>
> GUI is already different from the command line, see for example the
> guisection, that are not present in --help or manual.
>


>
> Of course we can add these information on the description, but often
> we have more than one parameter that depend from the same formula and
> I think that introduce something like the mockup could improve
> usability.
>
> _______________________________________________
> 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/4939338f/attachment.html>