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

Pietro2 · January 14, 2015, 8:42am

Dear devs,

sometimes I would like to add some multiline text on the module GUI to
help to understand the meaning of the parameter, and/or understand the
logic of the module.

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

for instance if I have two mutual exclusive options like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : no
#%end
#%option
#% type: description
#% answer: OR
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : no
#%end
}}}

So in the gui of the module I will have:

Raster input map:
-> raster menu

OR

Vector input map:
-> vector menu

or add a relation, to do something like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : yes
#%end
#%keyrelation: raster OR vector
}}}

Is it this possible already? If yes how? Do you have some links?

Do you think that would be feasible add also a LaTex option?
To do something like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% guisection: Costs
#% type: description
#% answer: This option is used to compute the total
#% cost of %%%% using this formula:
#%end
#%option
#%option
#% guisection: Costs
#% type: latex
#% answer: \rho = \frac{\gamma}{\pi}
#%end
#%option
#% guisection: Costs
#% key: gamma
#% type: double
#% description: $\gamma$ value
#% required : no
#% answer: 12.45
#%end
#%option
#% guisection: Costs
#% key: currency
#% type: string
#% description: the currency
#% required : no
#% answer: €
#%end
}}}

In this way the GUI could be more descriptive and clearer.

I have not idea if this could be feasible or not... What do you think?

Best regards

Pietro

ecodiv · January 14, 2015, 9:01am

+1 for adding description option

···

On Wed, Jan 14, 2015 at 9:42 AM, Pietro <peter.zamb@gmail.com> wrote:

Dear devs,

sometimes I would like to add some multiline text on the module GUI to
help to understand the meaning of the parameter, and/or understand the
logic of the module.

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

for instance if I have two mutual exclusive options like:

{{{
#%module
#% description: test script
#%end
…
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : no
#%end
#%option
#% type: description
#% answer: OR
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : no
#%end
}}}

So in the gui of the module I will have:

Raster input map:
→ raster menu

OR

Vector input map:
→ vector menu

or add a relation, to do something like:

{{{
#%module
#% description: test script
#%end
…
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : yes
#%end
#%keyrelation: raster OR vector
}}}

Is it this possible already? If yes how? Do you have some links?

Do you think that would be feasible add also a LaTex option?
To do something like:

{{{
#%module
#% description: test script
#%end
…
#%option
#% guisection: Costs
#% type: description
#% answer: This option is used to compute the total
#% cost of %%%% using this formula:
#%end
#%option
#%option
#% guisection: Costs
#% type: latex
#% answer: \rho = \frac{\gamma}{\pi}
#%end
#%option
#% guisection: Costs
#% key: gamma
#% type: double
#% description: $\gamma$ value
#% required : no
#% answer: 12.45
#%end
#%option
#% guisection: Costs
#% key: currency
#% type: string
#% description: the currency
#% required : no
#% answer: €
#%end
}}}

In this way the GUI could be more descriptive and clearer.

I have not idea if this could be feasible or not… What do you think?

Best regards

Pietro

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Nikos_Alexandris · January 14, 2015, 9:19am

Pietro,

this thread <http://lists.osgeo.org/pipermail/grass-dev/2014-November/071908.html> is of interest, I guess, as well.

+1 for LaTeX. That would be awesome.

Nikos

Pietro2 · January 14, 2015, 9:27am

On Wed, Jan 14, 2015 at 10:19 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

this thread
<http://lists.osgeo.org/pipermail/grass-dev/2014-November/071908.html> is
of interest, I guess, as well.

Thanks Nikos, I've missed this thread! It is really interesting
perhaps should be possible to highlight the option relationships in
the GUI module and make it clearer/evident?

mlennert · January 14, 2015, 9:33am

On 14/01/15 09:42, Pietro wrote:

Dear devs,

sometimes I would like to add some multiline text on the module GUI to
help to understand the meaning of the parameter, and/or understand the
logic of the module.

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

If you add

#% label

and

#% description

the label will be displayed as text in the window and the description will be put into a tooltip that pops up at mouse-over. You can then put as much text as you want into the description.

Moritz

Nikos_Alexandris · January 14, 2015, 10:07am

On 14/01/15 09:42, Pietro wrote:

Dear devs,
sometimes I would like to add some multiline text on the module GUI to
help to understand the meaning of the parameter, and/or understand the
logic of the module.
Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

On 14.01.2015 11:33, Moritz Lennert wrote:

If you add

#% label

and

#% description

the label will be displayed as text in the window and the description
will be put into a tooltip that pops up at mouse-over. You can then
put as much text as you want into the description.

Note though, too much text in the description, will overload the output of "?.SomeModule --help" in the command line.

Nikos

Pietro2 · January 14, 2015, 10:59am

On Wed, Jan 14, 2015 at 10:33 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

If you add

#% label

and

#% description

the label will be displayed as text in the window and the description will
be put into a tooltip that pops up at mouse-over. You can then put as much
text as you want into the description.

mmh... do you mean inside the option?

I would like something outside the option, something before or after
an option, at the moment I have a GUI with the form:

{{{
Raster input map:
-> raster menu

Vector input map:
-> vector menu
}}}

I would like to be able to add a text/latex in the middle to make the
GUI self-explanatory and relay less on the manual page.
to have something like:

{{{
Raster input map:
-> raster menu

Add some more text here (just text/latex, not input is required by users)

Vector input map:
-> vector menu
}}}

mlennert · January 14, 2015, 1:04pm

On 14/01/15 11:59, Pietro wrote:

On Wed, Jan 14, 2015 at 10:33 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

If you add

#% label

and

#% description

the label will be displayed as text in the window and the description will
be put into a tooltip that pops up at mouse-over. You can then put as much
text as you want into the description.

mmh... do you mean inside the option?

Yes, the tooltip is linked to the option.

I would like something outside the option, something before or after
an option, at the moment I have a GUI with the form:

{{{
Raster input map:
-> raster menu

Vector input map:
-> vector menu
}}}

I would like to be able to add a text/latex in the middle to make the
GUI self-explanatory and relay less on the manual page.
to have something like:

{{{
Raster input map:
-> raster menu

Add some more text here (just text/latex, not input is required by users)

Vector input map:
-> vector menu
}}}

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...

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.

Moritz

Pietro2 · January 14, 2015, 2:05pm

On Wed, Jan 14, 2015 at 2:04 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

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...

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.

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.

Best regards

Pietro

Huidae_Cho · January 14, 2015, 2:13pm

On Wed, Jan 14, 2015 at 3:42 AM, Pietro <peter.zamb@gmail.com> wrote:

Dear devs,

sometimes I would like to add some multiline text on the module GUI to
help to understand the meaning of the parameter, and/or understand the
logic of the module.

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

for instance if I have two mutual exclusive options like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : no
#%end
#%option
#% type: description
#% answer: OR
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : no
#%end
}}}

So in the gui of the module I will have:

Raster input map:
-> raster menu

OR

Vector input map:
-> vector menu

or add a relation, to do something like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : yes
#%end
#%keyrelation: raster OR vector
}}}

Is it this possible already? If yes how? Do you have some links?

Requiring raster OR vector is possible already.

#%rules
#% requires: raster, vector
#%end

Do you think that would be feasible add also a LaTex option?
To do something like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% guisection: Costs
#% type: description
#% answer: This option is used to compute the total
#% cost of %%%% using this formula:
#%end
#%option
#%option
#% guisection: Costs
#% type: latex
#% answer: \rho = \frac{\gamma}{\pi}
#%end
#%option
#% guisection: Costs
#% key: gamma
#% type: double
#% description: $\gamma$ value
#% required : no
#% answer: 12.45
#%end
#%option
#% guisection: Costs
#% key: currency
#% type: string
#% description: the currency
#% required : no
#% answer: €
#%end
}}}

In this way the GUI could be more descriptive and clearer.

I have not idea if this could be feasible or not... What do you think?

Best regards

Pietro
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

wenzeslaus · January 14, 2015, 2:59pm

On Wed, Jan 14, 2015 at 9:13 AM, Huidae Cho <grass4u@gmail.com> wrote:

On Wed, Jan 14, 2015 at 3:42 AM, Pietro <peter.zamb@gmail.com> wrote:

Dear devs,

sometimes I would like to add some multiline text on the module GUI to
help to understand the meaning of the parameter, and/or understand the
logic of the module.

Do you think that would be possible to have a description option that
it does not take any input but allow us to be more descriptive inside
the module interface?

for instance if I have two mutual exclusive options like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : no
#%end
#%option
#% type: description
#% answer: OR
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : no
#%end
}}}

So in the gui of the module I will have:

Raster input map:
-> raster menu

OR

Vector input map:
-> vector menu

or add a relation, to do something like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% key: raster
#% type: string
#% gisprompt: old,cell,raster
#% description: Raster input map:
#% required : yes
#%end
#%option
#% key: vector
#% type: string
#% gisprompt: old,vector,vector
#% description: Vector input map
#% required : yes
#%end
#%keyrelation: raster OR vector
}}}

Is it this possible already? If yes how? Do you have some links?

Requiring raster OR vector is possible already.

#%rules
#% requires: raster, vector
#%end

Can this have a description? I'm not sure where we would show it but it
might be useful. 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. 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.

Vaclav

Do you think that would be feasible add also a LaTex option?
To do something like:

{{{
#%module
#% description: test script
#%end
...
#%option
#% guisection: Costs
#% type: description
#% answer: This option is used to compute the total
#% cost of %%%% using this formula:
#%end
#%option
#%option
#% guisection: Costs
#% type: latex
#% answer: \rho = \frac{\gamma}{\pi}
#%end
#%option
#% guisection: Costs
#% key: gamma
#% type: double
#% description: $\gamma$ value
#% required : no
#% answer: 12.45
#%end
#%option
#% guisection: Costs
#% key: currency
#% type: string
#% description: the currency
#% required : no
#% answer: €
#%end
}}}

In this way the GUI could be more descriptive and clearer.

I have not idea if this could be feasible or not... What do you think?

Best regards

Pietro
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Pietro2 · January 14, 2015, 4:27pm

On Wed, Jan 14, 2015 at 3:59 PM, Vaclav Petras <wenzeslaus@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.

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. 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.

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.

(attachments)

ecodiv · January 14, 2015, 5:13pm

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

On Wed, Jan 14, 2015 at 3:59 PM, Vaclav Petras <wenzeslaus@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Nikos_Alexandris · January 14, 2015, 5:56pm

On 14.01.2015 16:13, Huidae Cho wrote:

[..]

Requiring raster OR vector is possible already.

#%rules
#% requires: raster, vector
#%end

Can't the above be reflected, when used, in the GUI in a way such as Pietro thinks?

Nikos

Nikos_Alexandris · January 14, 2015, 6:07pm

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.

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

Nikos_Alexandris · January 14, 2015, 6:15pm

On 14.01.2015 19:13, Paulo van Breugel wrote:

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).

I agree, tabbing is always efficient. Just an idea: instead of "tabbing", could the "guisection", or a similar function, stack stuff in a box with slightly, yet distiguishable, different colored background? Along with other stuff in the same tab?

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.

Note, the "tooltips" pop only when the cursor floats over some descriptive text. Can they also appear when the cursor points directly in an/the input box?

Nikos

annakrat · January 14, 2015, 6:18pm

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

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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

annakrat · January 14, 2015, 6:25pm

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

On 14.01.2015 19:13, Paulo van Breugel wrote:

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).

I agree, tabbing is always efficient. Just an idea: instead of
"tabbing", could the "guisection", or a similar function, stack stuff in a
box with slightly, yet distiguishable, different colored background? Along
with other stuff in the same tab?

I am not sure how this would work with wxPython, maybe possible, but isn't
it too complicated? There is still a lot modules which have terrible layout
of options and using current possibilities we can improve them. Let's do
that first. I don't say we shouldn't think about improvements in the
meantime.

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.

Note, the "tooltips" pop only when the cursor floats over some descriptive
text. Can they also appear when the cursor points directly in an/the input
box?

Yes, I know about it, that shouldn't be too difficult.

Nikos

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

ecodiv · January 14, 2015, 7:47pm

On Wed, Jan 14, 2015 at 7:25 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:

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

On 14.01.2015 19:13, Paulo van Breugel wrote:

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).

I agree, tabbing is always efficient. Just an idea: instead of
"tabbing", could the "guisection", or a similar function, stack stuff in a
box with slightly, yet distiguishable, different colored background? Along
with other stuff in the same tab?

I am not sure how this would work with wxPython, maybe possible, but isn't
it too complicated? There is still a lot modules which have terrible layout
of options and using current possibilities we can improve them. Let's do
that first. I don't say we shouldn't think about improvements in the
meantime.

This may be complicated in terms of programming, and I agree that in that
case it may not be a very high priority.. but from an interface point of
view, I think this is a very good idea, and it is something often used in
other programs. Another way of grouping used in menus of other programs is
headers for groups and indents, something like:

Option group 1
option 1
option 2
Option 3
Option 4

I guess that could work too if it is easier to implement than using
different background colours or borders.

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.

Note, the "tooltips" pop only when the cursor floats over some
descriptive text. Can they also appear when the cursor points directly in
an/the input box?

Yes, I know about it, that shouldn't be too difficult.

Nikos

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Glynn_Clements1 · January 15, 2015, 7:46am

Requiring raster OR vector is possible already.

#%rules
#% requires: raster, vector
#%end

This should be "required" (at least one of the options must be given).
If you want exactly one option to be given, you need both "required"
and "exclusive", e.g.

#%rules
#% required: raster, vector
#% exclusive: raster, vector
#%end

A "requires" rule indicates that if the first option is given, at
least one of the other options must be given.

--
Glynn Clements <glynn@gclements.plus.com>