[GRASS-dev] No Required GUI section for g.list and g.remove

[wenzeslaus]

Hi,

Anna and I discussed the GUI sections of g.list and g.remove. The changes are now in trunk (r62248). However, few issues still remain.

It seems to us that although names and ignore in g.remove are similar from the point of view of implementation, they have completely different use case. While names is here to provide a simple interface, ignore extends the interface which is using patterns. So, non-advanced user using GUI will surely want names but not ignore and GUI should reflect this. Thus ignore should probably go to Pattern (although it is not 100% consistent) and names to some basic category.

Also, Required section (of both g.remove and g.list) contains just one item - type. In case of g.remove, it could make sense to have the names together with type in some Basic section which would be the primary section users can focus on (besides approval by -f in Optional). This of course expects that no elements will be added to the type list (#2440, #2437).

So, the big question is if we want to allow Required section to be overridden by another section if it is provided. Currently if option is required, GUI puts it into Required section no matter if another GUI section was specified.

Thanks for your opinions,

Vaclav

r62248 http://trac.osgeo.org/grass/changeset/62248
#2440 http://trac.osgeo.org/grass/ticket/2440
#2437 http://trac.osgeo.org/grass/ticket/2437

[ecodiv]

Putting the ‘ignore’ option in separate tab with patterns is fine I think. Also, for g.remove to have the ‘type’ and ‘name’ together in one tab is also a good idea imho.

I am not sure I understand the last question; you mean to add the possibility to make an option required but still have the option to put it in another section? I think that would be a good idea, not only in this case, but more in general, it would make it easier to create an consistent interface for modules that require more than a few inputs. It might be a good idea to flag options as required, e.g., by adding ‘(required)’ after the option name?

On a side note, why the -f flag of g.remove is in the ‘optional’ tab? I understand it is optional, but as you noted, it is a primary option… it is essential to do what the function is suppose to do, remove layers. As a new user I would not expect such an essential option in the optional tab I think.

Paulo

···

On 14-10-14 04:17, Vaclav Petras wrote:

Hi,

Anna and I discussed the GUI sections of g.list and g.remove. The changes are now in trunk (r62248). However, few issues still remain.

It seems to us that although names and ignore in g.remove are similar from the point of view of implementation, they have completely different use case. While names is here to provide a simple interface, ignore extends the interface which is using patterns. So, non-advanced user using GUI will surely want names but not ignore and GUI should reflect this. Thus ignore should probably go to Pattern (although it is not 100% consistent) and names to some basic category.

Also, Required section (of both g.remove and g.list) contains just one item - type. In case of g.remove, it could make sense to have the names together with type in some Basic section which would be the primary section users can focus on (besides approval by -f in Optional). This of course expects that no elements will be added to the type list (#2440, #2437).

So, the big question is if we want to allow Required section to be overridden by another section if it is provided. Currently if option is required, GUI puts it into Required section no matter if another GUI section was specified.

Thanks for your opinions,

Vaclav

r62248 http://trac.osgeo.org/grass/changeset/62248
#2440 http://trac.osgeo.org/grass/ticket/2440
#2437 http://trac.osgeo.org/grass/ticket/2437

_______________________________________________
grass-dev mailing list
[grass-dev@lists.osgeo.org](mailto:grass-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-dev](http://lists.osgeo.org/mailman/listinfo/grass-dev)

[mlennert]

On 14/10/14 09:14, Paulo van Breugel wrote:

Putting the 'ignore' option in separate tab with patterns is fine I
think. Also, for g.remove to have the 'type' and 'name' together in one
tab is also a good idea imho.

I am not sure I understand the last question; you mean to add the
possibility to make an option required but still have the option to put
it in another section? I think that would be a good idea, not only in
this case, but more in general, it would make it easier to create an
consistent interface for modules that require more than a few inputs.
It might be a good idea to flag options as required, e.g., by adding
'(required)' after the option name?

I'm not sure I agree with this as this would leave the door open for required flags to be disseminated across several sections. I like the fact that the use immediately sees what is required to run the module.

Moritz

[ecodiv]

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 14/10/14 09:14, Paulo van Breugel wrote:

Putting the 'ignore' option in separate tab with patterns is fine I
think. Also, for g.remove to have the 'type' and 'name' together in one
tab is also a good idea imho.

I am not sure I understand the last question; you mean to add the
possibility to make an option required but still have the option to put
it in another section? I think that would be a good idea, not only in
this case, but more in general, it would make it easier to create an
consistent interface for modules that require more than a few inputs.
It might be a good idea to flag options as required, e.g., by adding
'(required)' after the option name?

I'm not sure I agree with this as this would leave the door open for
required flags to be disseminated across several sections. I like the fact
that the use immediately sees what is required to run the module.

I guess it is a matter of preference. There are some grey area or cases
where this separate 'required' tab does not really work i.m.h.o.

The '-f' flag in g.remove is one example. You can run the module without
(so it shouldn't go in the 'required' tab), but you can't do what the
module is basically meant to do without it, which is removing layers (so in
that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is the
output layer. That can be a raster layer, a vector layer or both. Because
of this construct, the required output name cannot be marked as required.
Solution is to use a separate tab 'optional' where the user can provide the
output name of the vector, raster or both layers. So the user has to fill
in required information in a 'required tab' and an 'optional' tab. I don't
think it is really problematic as failing to give the output name results
in a clear error message, but it isn't exactly consistent.

But at the end, for me any solution would be fine, as long as it is clearly
described and error messages are clear (and it would of course be nice if
where possible the number of clicks or scrolling are minimized).

Moritz

[mlennert]

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

    On 14/10/14 09:14, Paulo van Breugel wrote:

        Putting the 'ignore' option in separate tab with patterns is fine I
        think. Also, for g.remove to have the 'type' and 'name' together
        in one
        tab is also a good idea imho.

        I am not sure I understand the last question; you mean to add the
        possibility to make an option required but still have the option
        to put
        it in another section? I think that would be a good idea, not
        only in
        this case, but more in general, it would make it easier to create an
        consistent interface for modules that require more than a few
        inputs.
        It might be a good idea to flag options as required, e.g., by adding
        '(required)' after the option name?

    I'm not sure I agree with this as this would leave the door open for
    required flags to be disseminated across several sections. I like
    the fact that the use immediately sees what is required to run the
    module.

I guess it is a matter of preference. There are some grey area or cases
where this separate 'required' tab does not really work i.m.h.o.

The '-f' flag in g.remove is one example. You can run the module without
(so it shouldn't go in the 'required' tab), but you can't do what the
module is basically meant to do without it, which is removing layers (so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is the
output layer. That can be a raster layer, a vector layer or both.
Because of this construct, the required output name cannot be marked as
required. Solution is to use a separate tab 'optional' where the user
can provide the output name of the vector, raster or both layers. So the
user has to fill in required information in a 'required tab' and an
'optional' tab. I don't think it is really problematic as failing to
give the output name results in a clear error message, but it isn't
exactly consistent.

The new options to declare parameters as mutually exclusive or as "at least one is requried of the group" might be a solution to that, but no idea how to implement this in the GUI.

If we want to go a simpler road, I think I would be more in favour of allowing some optional parameters in the required section (but marking them clearly as optional), than to move any required parameters to other sections than 'Required'.

Moritz

[wenzeslaus]

On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 14/10/14 09:14, Paulo van Breugel wrote:

        Putting the 'ignore' option in separate tab with patterns is
fine I
        think. Also, for g.remove to have the 'type' and 'name' together
        in one
        tab is also a good idea imho.

        I am not sure I understand the last question; you mean to add the
        possibility to make an option required but still have the option
        to put
        it in another section? I think that would be a good idea, not
        only in
        this case, but more in general, it would make it easier to create
an
        consistent interface for modules that require more than a few
        inputs.
        It might be a good idea to flag options as required, e.g., by
adding
        '(required)' after the option name?

    I'm not sure I agree with this as this would leave the door open for
    required flags to be disseminated across several sections. I like
    the fact that the use immediately sees what is required to run the
    module.

I guess it is a matter of preference. There are some grey area or cases
where this separate 'required' tab does not really work i.m.h.o.

The '-f' flag in g.remove is one example. You can run the module without
(so it shouldn't go in the 'required' tab), but you can't do what the
module is basically meant to do without it, which is removing layers (so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is the
output layer. That can be a raster layer, a vector layer or both.
Because of this construct, the required output name cannot be marked as
required. Solution is to use a separate tab 'optional' where the user
can provide the output name of the vector, raster or both layers. So the
user has to fill in required information in a 'required tab' and an
'optional' tab. I don't think it is really problematic as failing to
give the output name results in a clear error message, but it isn't
exactly consistent.

The new options to declare parameters as mutually exclusive or as "at
least one is requried of the group" might be a solution to that, but no
idea how to implement this in the GUI.

Put this to GUI is certainly needed but challenging and I it will not be

included in 7.0. Perhaps we should put this to the manual in some way. But
modules are not using it anyway.

Anyway, these "at least one required" are causing Required section to be
less and less used, so that's another reason why it makes sense to leave it
out sometimes.

If we want to go a simpler road, I think I would be more in favour of
allowing some optional parameters in the required section (but marking them
clearly as optional), than to move any required parameters to other
sections than 'Required'.

I think that the opposite is true. Having 'optional' in Required section

would defeat the purpose of Required section. And if we consider that
options which are in group "one of them required" are spread in other
sections than Required, then putting standard 'required' options to other
sections is nothing new.

And yes, we need to go a simpler road for now.

Vaclav

Moritz

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

[annakrat]

Hi,

···

On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

I think it makes thanks to ‘override’ the required property with the guisection. If we do it for a module, we should make sure there is no Required tab at all. I think having required parameters in custom tabs and eliminate Required tab is totally fine. Having Required tab and at the same time have required parameters in other sections would not work well.

Also we could mark the required options in the gui somehow, for example add a red star? In the code I see attempts to render the labels as bold, it is not used eventually, but I don’t think bold is the best way anyway.

Anna

---

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

On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert

<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)> wrote:

On 14/10/14 09:14, Paulo van Breugel wrote:

Putting the ‘ignore’ option in separate tab with patterns is fine I
think. Also, for g.remove to have the ‘type’ and ‘name’ together
in one
tab is also a good idea imho.

I am not sure I understand the last question; you mean to add the
possibility to make an option required but still have the option
to put
it in another section? I think that would be a good idea, not
only in
this case, but more in general, it would make it easier to create an
consistent interface for modules that require more than a few
inputs.
It might be a good idea to flag options as required, e.g., by adding
‘(required)’ after the option name?

I’m not sure I agree with this as this would leave the door open for
required flags to be disseminated across several sections. I like
the fact that the use immediately sees what is required to run the
module.

I guess it is a matter of preference. There are some grey area or cases
where this separate ‘required’ tab does not really work i.m.h.o.

The ‘-f’ flag in g.remove is one example. You can run the module without
(so it shouldn’t go in the ‘required’ tab), but you can’t do what the
module is basically meant to do without it, which is removing layers (so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is the
output layer. That can be a raster layer, a vector layer or both.
Because of this construct, the required output name cannot be marked as
required. Solution is to use a separate tab ‘optional’ where the user
can provide the output name of the vector, raster or both layers. So the
user has to fill in required information in a ‘required tab’ and an
‘optional’ tab. I don’t think it is really problematic as failing to
give the output name results in a clear error message, but it isn’t
exactly consistent.

The new options to declare parameters as mutually exclusive or as “at least one is requried of the group” might be a solution to that, but no idea how to implement this in the GUI.

Put this to GUI is certainly needed but challenging and I it will not be included in 7.0. Perhaps we should put this to the manual in some way. But modules are not using it anyway.

Anyway, these “at least one required” are causing Required section to be less and less used, so that’s another reason why it makes sense to leave it out sometimes.

If we want to go a simpler road, I think I would be more in favour of allowing some optional parameters in the required section (but marking them clearly as optional), than to move any required parameters to other sections than ‘Required’.

I think that the opposite is true. Having ‘optional’ in Required section would defeat the purpose of Required section. And if we consider that options which are in group “one of them required” are spread in other sections than Required, then putting standard ‘required’ options to other sections is nothing new.

And yes, we need to go a simpler road for now.

Vaclav

Moritz

---

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

[annakrat]

Hi,

(attachments)

···

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com> wrote:

Hi,

I attached screenshots with using the red star for required options (and in this case I was also testing when the guisection is preferred to required). In my opinion, it gives you good idea what is required or not. There are some problems coming from the wxPython limitations, for example the one which you see on the second screenshot: when the label is part of the border, I can’t set the asterisk red, the color can be changed only for the entire label. But for majority options, it works.

Regarding the required vs. guisection, I really think we should try to organize the options logically, not based on required/optional. Some distinction of the required options is then needed and the red asterisk seems to be a good solution. But we can discuss some other options too, of course.

Anna

On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

I think it makes thanks to ‘override’ the required property with the guisection. If we do it for a module, we should make sure there is no Required tab at all. I think having required parameters in custom tabs and eliminate Required tab is totally fine. Having Required tab and at the same time have required parameters in other sections would not work well.

Also we could mark the required options in the gui somehow, for example add a red star? In the code I see attempts to render the labels as bold, it is not used eventually, but I don’t think bold is the best way anyway.

On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert

<mlennert@club.worldonline.be mailto:[mlennert@club.worldonline.be](mailto:mlennert@club.worldonline.be)> wrote:

On 14/10/14 09:14, Paulo van Breugel wrote:

Putting the ‘ignore’ option in separate tab with patterns is fine I
think. Also, for g.remove to have the ‘type’ and ‘name’ together
in one
tab is also a good idea imho.

I am not sure I understand the last question; you mean to add the
possibility to make an option required but still have the option
to put
it in another section? I think that would be a good idea, not
only in
this case, but more in general, it would make it easier to create an
consistent interface for modules that require more than a few
inputs.
It might be a good idea to flag options as required, e.g., by adding
‘(required)’ after the option name?

I’m not sure I agree with this as this would leave the door open for
required flags to be disseminated across several sections. I like
the fact that the use immediately sees what is required to run the
module.

I guess it is a matter of preference. There are some grey area or cases
where this separate ‘required’ tab does not really work i.m.h.o.

The ‘-f’ flag in g.remove is one example. You can run the module without
(so it shouldn’t go in the ‘required’ tab), but you can’t do what the
module is basically meant to do without it, which is removing layers (so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is the
output layer. That can be a raster layer, a vector layer or both.
Because of this construct, the required output name cannot be marked as
required. Solution is to use a separate tab ‘optional’ where the user
can provide the output name of the vector, raster or both layers. So the
user has to fill in required information in a ‘required tab’ and an
‘optional’ tab. I don’t think it is really problematic as failing to
give the output name results in a clear error message, but it isn’t
exactly consistent.

The new options to declare parameters as mutually exclusive or as “at least one is requried of the group” might be a solution to that, but no idea how to implement this in the GUI.

Put this to GUI is certainly needed but challenging and I it will not be included in 7.0. Perhaps we should put this to the manual in some way. But modules are not using it anyway.

Anyway, these “at least one required” are causing Required section to be less and less used, so that’s another reason why it makes sense to leave it out sometimes.

Anna

---

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

If we want to go a simpler road, I think I would be more in favour of allowing some optional parameters in the required section (but marking them clearly as optional), than to move any required parameters to other sections than ‘Required’.

I think that the opposite is true. Having ‘optional’ in Required section would defeat the purpose of Required section. And if we consider that options which are in group “one of them required” are spread in other sections than Required, then putting standard ‘required’ options to other sections is nothing new.

And yes, we need to go a simpler road for now.

Vaclav

Moritz

---

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

[ecodiv]

On Sat, Oct 25, 2014 at 2:58 AM, Anna Petrášová <kratochanna@gmail.com>
wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com>
wrote:

Hi,

On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 14/10/14 09:14, Paulo van Breugel wrote:

        Putting the 'ignore' option in separate tab with patterns is
fine I
        think. Also, for g.remove to have the 'type' and 'name'
together
        in one
        tab is also a good idea imho.

        I am not sure I understand the last question; you mean to add
the
        possibility to make an option required but still have the
option
        to put
        it in another section? I think that would be a good idea, not
        only in
        this case, but more in general, it would make it easier to
create an
        consistent interface for modules that require more than a few
        inputs.
        It might be a good idea to flag options as required, e.g., by
adding
        '(required)' after the option name?

    I'm not sure I agree with this as this would leave the door open
for
    required flags to be disseminated across several sections. I like
    the fact that the use immediately sees what is required to run the
    module.

I guess it is a matter of preference. There are some grey area or cases
where this separate 'required' tab does not really work i.m.h.o.

The '-f' flag in g.remove is one example. You can run the module
without
(so it shouldn't go in the 'required' tab), but you can't do what the
module is basically meant to do without it, which is removing layers
(so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is
the
output layer. That can be a raster layer, a vector layer or both.
Because of this construct, the required output name cannot be marked as
required. Solution is to use a separate tab 'optional' where the user
can provide the output name of the vector, raster or both layers. So
the
user has to fill in required information in a 'required tab' and an
'optional' tab. I don't think it is really problematic as failing to
give the output name results in a clear error message, but it isn't
exactly consistent.

The new options to declare parameters as mutually exclusive or as "at
least one is requried of the group" might be a solution to that, but no
idea how to implement this in the GUI.

Put this to GUI is certainly needed but challenging and I it will not

be included in 7.0. Perhaps we should put this to the manual in some way.
But modules are not using it anyway.

Anyway, these "at least one required" are causing Required section to be
less and less used, so that's another reason why it makes sense to leave it
out sometimes.

I think it makes thanks to 'override' the required property with the
guisection. If we do it for a module, we should make sure there is no
Required tab at all. I think having required parameters in custom tabs and
eliminate Required tab is totally fine. Having Required tab and at the same
time have required parameters in other sections would not work well.

Also we could mark the required options in the gui somehow, for example
add a red star? In the code I see attempts to render the labels as bold, it
is not used eventually, but I don't think bold is the best way anyway.

I attached screenshots with using the red star for required options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or not.
There are some problems coming from the wxPython limitations, for example
the one which you see on the second screenshot: when the label is part of
the border, I can't set the asterisk red, the color can be changed only for
the entire label. But for majority options, it works.

This is excellent. Red stars are nice but even in grey it works fine. It is
a fairly common practise to mark required options / entries this way so
this will probably work for most users

Regarding the required vs. guisection, I really think we should try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red asterisk
seems to be a good solution. But we can discuss some other options too, of
course.

I totally agree, I think this is the way to go.

Anna

Anna

If we want to go a simpler road, I think I would be more in favour of
allowing some optional parameters in the required section (but marking them
clearly as optional), than to move any required parameters to other
sections than 'Required'.

I think that the opposite is true. Having 'optional' in Required

section would defeat the purpose of Required section. And if we consider
that options which are in group "one of them required" are spread in other
sections than Required, then putting standard 'required' options to other
sections is nothing new.

And yes, we need to go a simpler road for now.

Vaclav

Moritz

_______________________________________________
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

[annakrat]

On Sat, Oct 25, 2014 at 4:55 AM, Paulo van Breugel <p.vanbreugel@gmail.com>
wrote:

On Sat, Oct 25, 2014 at 2:58 AM, Anna Petrášová <kratochanna@gmail.com>
wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com>
wrote:

Hi,

On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:

On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 14/10/14 09:14, Paulo van Breugel wrote:

        Putting the 'ignore' option in separate tab with patterns is
fine I
        think. Also, for g.remove to have the 'type' and 'name'
together
        in one
        tab is also a good idea imho.

        I am not sure I understand the last question; you mean to add
the
        possibility to make an option required but still have the
option
        to put
        it in another section? I think that would be a good idea, not
        only in
        this case, but more in general, it would make it easier to
create an
        consistent interface for modules that require more than a few
        inputs.
        It might be a good idea to flag options as required, e.g., by
adding
        '(required)' after the option name?

    I'm not sure I agree with this as this would leave the door open
for
    required flags to be disseminated across several sections. I like
    the fact that the use immediately sees what is required to run the
    module.

I guess it is a matter of preference. There are some grey area or
cases
where this separate 'required' tab does not really work i.m.h.o.

The '-f' flag in g.remove is one example. You can run the module
without
(so it shouldn't go in the 'required' tab), but you can't do what the
module is basically meant to do without it, which is removing layers
(so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the required options is
the
output layer. That can be a raster layer, a vector layer or both.
Because of this construct, the required output name cannot be marked
as
required. Solution is to use a separate tab 'optional' where the user
can provide the output name of the vector, raster or both layers. So
the
user has to fill in required information in a 'required tab' and an
'optional' tab. I don't think it is really problematic as failing to
give the output name results in a clear error message, but it isn't
exactly consistent.

The new options to declare parameters as mutually exclusive or as "at
least one is requried of the group" might be a solution to that, but no
idea how to implement this in the GUI.

Put this to GUI is certainly needed but challenging and I it will not

be included in 7.0. Perhaps we should put this to the manual in some way.
But modules are not using it anyway.

Anyway, these "at least one required" are causing Required section to
be less and less used, so that's another reason why it makes sense to leave
it out sometimes.

I think it makes thanks to 'override' the required property with the
guisection. If we do it for a module, we should make sure there is no
Required tab at all. I think having required parameters in custom tabs and
eliminate Required tab is totally fine. Having Required tab and at the same
time have required parameters in other sections would not work well.

Also we could mark the required options in the gui somehow, for example
add a red star? In the code I see attempts to render the labels as bold, it
is not used eventually, but I don't think bold is the best way anyway.

I attached screenshots with using the red star for required options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or not.
There are some problems coming from the wxPython limitations, for example
the one which you see on the second screenshot: when the label is part of
the border, I can't set the asterisk red, the color can be changed only for
the entire label. But for majority options, it works.

This is excellent. Red stars are nice but even in grey it works fine. It
is a fairly common practise to mark required options / entries this way so
this will probably work for most users

Regarding the required vs. guisection, I really think we should try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red asterisk
seems to be a good solution. But we can discuss some other options too, of
course.

I totally agree, I think this is the way to go.

I committed it in r62403. I will have to adjust guisections in several
modules to reflect the changes.

Anna

Anna

If we want to go a simpler road, I think I would be more in favour of
allowing some optional parameters in the required section (but marking them
clearly as optional), than to move any required parameters to other
sections than 'Required'.

I think that the opposite is true. Having 'optional' in Required

section would defeat the purpose of Required section. And if we consider
that options which are in group "one of them required" are spread in other
sections than Required, then putting standard 'required' options to other
sections is nothing new.

And yes, we need to go a simpler road for now.

Vaclav

Moritz

_______________________________________________
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

[mlennert]

On 25/10/14 02:58, Anna Petrášová wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com
<mailto:kratochanna@gmail.com>> wrote:

    Hi,

    On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com
    <mailto:wenzeslaus@gmail.com>> wrote:

        On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>> wrote:

            On 14/10/14 10:38, Paulo van Breugel wrote:

                On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                <mlennert@club.worldonline.be
                <mailto:mlennert@club.worldonline.be>
                <mailto:mlennert@club.__worldonline.be
                <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 09:14, Paulo van Breugel wrote:

                         Putting the 'ignore' option in separate tab
                with patterns is fine I
                         think. Also, for g.remove to have the 'type'
                and 'name' together
                         in one
                         tab is also a good idea imho.

                         I am not sure I understand the last question;
                you mean to add the
                         possibility to make an option required but
                still have the option
                         to put
                         it in another section? I think that would be a
                good idea, not
                         only in
                         this case, but more in general, it would make
                it easier to create an
                         consistent interface for modules that require
                more than a few
                         inputs.
                         It might be a good idea to flag options as
                required, e.g., by adding
                         '(required)' after the option name?

                     I'm not sure I agree with this as this would leave
                the door open for
                     required flags to be disseminated across several
                sections. I like
                     the fact that the use immediately sees what is
                required to run the
                     module.

                I guess it is a matter of preference. There are some
                grey area or cases
                where this separate 'required' tab does not really work
                i.m.h.o.

                The '-f' flag in g.remove is one example. You can run
                the module without
                (so it shouldn't go in the 'required' tab), but you
                can't do what the
                module is basically meant to do without it, which is
                removing layers (so
                in that sense it should be a required choice).

                Perhaps a better example is r.random. One of the
                required options is the
                output layer. That can be a raster layer, a vector layer
                or both.
                Because of this construct, the required output name
                cannot be marked as
                required. Solution is to use a separate tab 'optional'
                where the user
                can provide the output name of the vector, raster or
                both layers. So the
                user has to fill in required information in a 'required
                tab' and an
                'optional' tab. I don't think it is really problematic
                as failing to
                give the output name results in a clear error message,
                but it isn't
                exactly consistent.

            The new options to declare parameters as mutually exclusive
            or as "at least one is requried of the group" might be a
            solution to that, but no idea how to implement this in the GUI.

        Put this to GUI is certainly needed but challenging and I it
        will not be included in 7.0. Perhaps we should put this to the
        manual in some way. But modules are not using it anyway.

        Anyway, these "at least one required" are causing Required
        section to be less and less used, so that's another reason why
        it makes sense to leave it out sometimes.

    I think it makes thanks to 'override' the required property with the
    guisection. If we do it for a module, we should make sure there is
    no Required tab at all. I think having required parameters in custom
    tabs and eliminate Required tab is totally fine. Having Required tab
    and at the same time have required parameters in other sections
    would not work well.

    Also we could mark the required options in the gui somehow, for
    example add a red star? In the code I see attempts to render the
    labels as bold, it is not used eventually, but I don't think bold is
    the best way anyway.

I attached screenshots with using the red star for required options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or
not. There are some problems coming from the wxPython limitations, for
example the one which you see on the second screenshot: when the label
is part of the border, I can't set the asterisk red, the color can be
changed only for the entire label. But for majority options, it works.

Regarding the required vs. guisection, I really think we should try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red asterisk
seems to be a good solution. But we can discuss some other options too,
of course.

If you really want to go down that path (it would get a 0 from me), then please remove the required tab completely. It will be very confusing to have a required section, but not with all required parameters in it.

I personally like the way the required tab focuses attention on the most important parameters, even though I do understand that there are ambiguities that this system creates. I'm not sure, though, that getting rid of the required tab is the solution. But if you go in that direction it should be all the way.

Moritz

Moritz

[wenzeslaus]

On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 25/10/14 02:58, Anna Petrášová wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com
<mailto:kratochanna@gmail.com>> wrote:

    Hi,

    On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com
    <mailto:wenzeslaus@gmail.com>> wrote:

        On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>> wrote:

            On 14/10/14 10:38, Paulo van Breugel wrote:

                On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                <mlennert@club.worldonline.be
                <mailto:mlennert@club.worldonline.be>
                <mailto:mlennert@club.__worldonline.be

                <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 09:14, Paulo van Breugel wrote:

                         Putting the 'ignore' option in separate tab
                with patterns is fine I
                         think. Also, for g.remove to have the 'type'
                and 'name' together
                         in one
                         tab is also a good idea imho.

                         I am not sure I understand the last question;
                you mean to add the
                         possibility to make an option required but
                still have the option
                         to put
                         it in another section? I think that would be a
                good idea, not
                         only in
                         this case, but more in general, it would make
                it easier to create an
                         consistent interface for modules that require
                more than a few
                         inputs.
                         It might be a good idea to flag options as
                required, e.g., by adding
                         '(required)' after the option name?

                     I'm not sure I agree with this as this would leave
                the door open for
                     required flags to be disseminated across several
                sections. I like
                     the fact that the use immediately sees what is
                required to run the
                     module.

                I guess it is a matter of preference. There are some
                grey area or cases
                where this separate 'required' tab does not really work
                i.m.h.o.

                The '-f' flag in g.remove is one example. You can run
                the module without
                (so it shouldn't go in the 'required' tab), but you
                can't do what the
                module is basically meant to do without it, which is
                removing layers (so
                in that sense it should be a required choice).

                Perhaps a better example is r.random. One of the
                required options is the
                output layer. That can be a raster layer, a vector layer
                or both.
                Because of this construct, the required output name
                cannot be marked as
                required. Solution is to use a separate tab 'optional'
                where the user
                can provide the output name of the vector, raster or
                both layers. So the
                user has to fill in required information in a 'required
                tab' and an
                'optional' tab. I don't think it is really problematic
                as failing to
                give the output name results in a clear error message,
                but it isn't
                exactly consistent.

            The new options to declare parameters as mutually exclusive
            or as "at least one is requried of the group" might be a
            solution to that, but no idea how to implement this in the
GUI.

        Put this to GUI is certainly needed but challenging and I it
        will not be included in 7.0. Perhaps we should put this to the
        manual in some way. But modules are not using it anyway.

        Anyway, these "at least one required" are causing Required
        section to be less and less used, so that's another reason why
        it makes sense to leave it out sometimes.

    I think it makes thanks to 'override' the required property with the
    guisection. If we do it for a module, we should make sure there is
    no Required tab at all. I think having required parameters in custom
    tabs and eliminate Required tab is totally fine. Having Required tab
    and at the same time have required parameters in other sections
    would not work well.

    Also we could mark the required options in the gui somehow, for
    example add a red star? In the code I see attempts to render the
    labels as bold, it is not used eventually, but I don't think bold is
    the best way anyway.

I attached screenshots with using the red star for required options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or
not. There are some problems coming from the wxPython limitations, for
example the one which you see on the second screenshot: when the label
is part of the border, I can't set the asterisk red, the color can be
changed only for the entire label. But for majority options, it works.

Regarding the required vs. guisection, I really think we should try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red asterisk
seems to be a good solution. But we can discuss some other options too,
of course.

If you really want to go down that path (it would get a 0 from me), then
please remove the required tab completely. It will be very confusing to
have a required section, but not with all required parameters in it.

Right. The modules which have required options in some other sections than

Required, should not have the Required section.

I personally like the way the required tab focuses attention on the most
important parameters, even though I do understand that there are
ambiguities that this system creates. I'm not sure, though, that getting
rid of the required tab is the solution. But if you go in that direction it
should be all the way.

We are not getting rid of it completely. If it is appropriate for the

module, it can use it. It is still the default. The point is that for some
modules there is no Required tab because of different ways to specify
inputs (e.g. map names in file vs map names in parameter) and for some of
the modules there is more logical way of organizing parameters than
Required vs optional (Optional section or general sections). Enabling
required parameters outside Required section is addressing the later case.

Moritz

Moritz

[ecodiv]

On Tue, Oct 28, 2014 at 3:31 PM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 25/10/14 02:58, Anna Petrášová wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com
<mailto:kratochanna@gmail.com>> wrote:

    Hi,

    On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com
    <mailto:wenzeslaus@gmail.com>> wrote:

        On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>> wrote:

            On 14/10/14 10:38, Paulo van Breugel wrote:

                On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                <mlennert@club.worldonline.be
                <mailto:mlennert@club.worldonline.be>
                <mailto:mlennert@club.__worldonline.be
                <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 09:14, Paulo van Breugel wrote:

                         Putting the 'ignore' option in separate tab
                with patterns is fine I
                         think. Also, for g.remove to have the 'type'
                and 'name' together
                         in one
                         tab is also a good idea imho.

                         I am not sure I understand the last question;
                you mean to add the
                         possibility to make an option required but
                still have the option
                         to put
                         it in another section? I think that would be a
                good idea, not
                         only in
                         this case, but more in general, it would make
                it easier to create an
                         consistent interface for modules that require
                more than a few
                         inputs.
                         It might be a good idea to flag options as
                required, e.g., by adding
                         '(required)' after the option name?

                     I'm not sure I agree with this as this would leave
                the door open for
                     required flags to be disseminated across several
                sections. I like
                     the fact that the use immediately sees what is
                required to run the
                     module.

                I guess it is a matter of preference. There are some
                grey area or cases
                where this separate 'required' tab does not really work
                i.m.h.o.

                The '-f' flag in g.remove is one example. You can run
                the module without
                (so it shouldn't go in the 'required' tab), but you
                can't do what the
                module is basically meant to do without it, which is
                removing layers (so
                in that sense it should be a required choice).

                Perhaps a better example is r.random. One of the
                required options is the
                output layer. That can be a raster layer, a vector layer
                or both.
                Because of this construct, the required output name
                cannot be marked as
                required. Solution is to use a separate tab 'optional'
                where the user
                can provide the output name of the vector, raster or
                both layers. So the
                user has to fill in required information in a 'required
                tab' and an
                'optional' tab. I don't think it is really problematic
                as failing to
                give the output name results in a clear error message,
                but it isn't
                exactly consistent.

            The new options to declare parameters as mutually exclusive
            or as "at least one is requried of the group" might be a
            solution to that, but no idea how to implement this in the
GUI.

        Put this to GUI is certainly needed but challenging and I it
        will not be included in 7.0. Perhaps we should put this to the
        manual in some way. But modules are not using it anyway.

        Anyway, these "at least one required" are causing Required
        section to be less and less used, so that's another reason why
        it makes sense to leave it out sometimes.

    I think it makes thanks to 'override' the required property with the
    guisection. If we do it for a module, we should make sure there is
    no Required tab at all. I think having required parameters in custom
    tabs and eliminate Required tab is totally fine. Having Required tab
    and at the same time have required parameters in other sections
    would not work well.

    Also we could mark the required options in the gui somehow, for
    example add a red star? In the code I see attempts to render the
    labels as bold, it is not used eventually, but I don't think bold is
    the best way anyway.

I attached screenshots with using the red star for required options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or
not. There are some problems coming from the wxPython limitations, for
example the one which you see on the second screenshot: when the label
is part of the border, I can't set the asterisk red, the color can be
changed only for the entire label. But for majority options, it works.

Regarding the required vs. guisection, I really think we should try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red asterisk
seems to be a good solution. But we can discuss some other options too,
of course.

If you really want to go down that path (it would get a 0 from me), then
please remove the required tab completely. It will be very confusing to
have a required section, but not with all required parameters in it.

Agree

I personally like the way the required tab focuses attention on the most
important parameters, even though I do understand that there are
ambiguities that this system creates. I'm not sure, though, that getting
rid of the required tab is the solution. But if you go in that direction it
should be all the way.

I understand these boil down to different preferences.. but just to argue
further in favour of the proposed changes.. from my own user experience,
and now from trying to train a colleague in using GRASS GIS.. what most
unambiguously focusses attention to the most important parameters is the
initial tab that opens when opening the window. This is now most often the
'required' tab, but it needn't be.

Moritz

Moritz

[annakrat]

On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 25/10/14 02:58, Anna Petrášová wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna@gmail.com
<mailto:kratochanna@gmail.com>> wrote:

    Hi,

    On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus@gmail.com
    <mailto:wenzeslaus@gmail.com>> wrote:

        On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
        <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>> wrote:

            On 14/10/14 10:38, Paulo van Breugel wrote:

                On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                <mlennert@club.worldonline.be
                <mailto:mlennert@club.worldonline.be>
                <mailto:mlennert@club.__worldonline.be

                <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 09:14, Paulo van Breugel wrote:

                         Putting the 'ignore' option in separate tab
                with patterns is fine I
                         think. Also, for g.remove to have the 'type'
                and 'name' together
                         in one
                         tab is also a good idea imho.

                         I am not sure I understand the last question;
                you mean to add the
                         possibility to make an option required but
                still have the option
                         to put
                         it in another section? I think that would be a
                good idea, not
                         only in
                         this case, but more in general, it would make
                it easier to create an
                         consistent interface for modules that require
                more than a few
                         inputs.
                         It might be a good idea to flag options as
                required, e.g., by adding
                         '(required)' after the option name?

                     I'm not sure I agree with this as this would leave
                the door open for
                     required flags to be disseminated across several
                sections. I like
                     the fact that the use immediately sees what is
                required to run the
                     module.

                I guess it is a matter of preference. There are some
                grey area or cases
                where this separate 'required' tab does not really work
                i.m.h.o.

                The '-f' flag in g.remove is one example. You can run
                the module without
                (so it shouldn't go in the 'required' tab), but you
                can't do what the
                module is basically meant to do without it, which is
                removing layers (so
                in that sense it should be a required choice).

                Perhaps a better example is r.random. One of the
                required options is the
                output layer. That can be a raster layer, a vector layer
                or both.
                Because of this construct, the required output name
                cannot be marked as
                required. Solution is to use a separate tab 'optional'
                where the user
                can provide the output name of the vector, raster or
                both layers. So the
                user has to fill in required information in a 'required
                tab' and an
                'optional' tab. I don't think it is really problematic
                as failing to
                give the output name results in a clear error message,
                but it isn't
                exactly consistent.

            The new options to declare parameters as mutually exclusive
            or as "at least one is requried of the group" might be a
            solution to that, but no idea how to implement this in the
GUI.

        Put this to GUI is certainly needed but challenging and I it
        will not be included in 7.0. Perhaps we should put this to the
        manual in some way. But modules are not using it anyway.

        Anyway, these "at least one required" are causing Required
        section to be less and less used, so that's another reason why
        it makes sense to leave it out sometimes.

    I think it makes thanks to 'override' the required property with the
    guisection. If we do it for a module, we should make sure there is
    no Required tab at all. I think having required parameters in custom
    tabs and eliminate Required tab is totally fine. Having Required tab
    and at the same time have required parameters in other sections
    would not work well.

    Also we could mark the required options in the gui somehow, for
    example add a red star? In the code I see attempts to render the
    labels as bold, it is not used eventually, but I don't think bold is
    the best way anyway.

I attached screenshots with using the red star for required options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or
not. There are some problems coming from the wxPython limitations, for
example the one which you see on the second screenshot: when the label
is part of the border, I can't set the asterisk red, the color can be
changed only for the entire label. But for majority options, it works.

Regarding the required vs. guisection, I really think we should try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red asterisk
seems to be a good solution. But we can discuss some other options too,
of course.

If you really want to go down that path (it would get a 0 from me), then
please remove the required tab completely. It will be very confusing to
have a required section, but not with all required parameters in it.

I personally like the way the required tab focuses attention on the most
important parameters, even though I do understand that there are
ambiguities that this system creates. I'm not sure, though, that getting
rid of the required tab is the solution. But if you go in that direction it
should be all the way.

Well, there are already modules which already don't have required tab
(r.colors, many t.* modules). Also a lot of modules have required tab but
it is more confusing than helpful. Do you require to remove Required tab
from all the modules? Even from modules where it still makes sense? Or you
are talking about the case when the option is required but the guisection
is specified, so it would get into a different tab? For the first option,
we would have to go through all modules (several hundreds) and come up with
some substitute, that's not feasible.

Anna

Moritz

Moritz

[mlennert]

On 28/10/14 16:40, Anna Petrášová wrote:

On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>> wrote:

    On 25/10/14 02:58, Anna Petrášová wrote:

        Hi,

        On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová
        <kratochanna@gmail.com <mailto:kratochanna@gmail.com>
        <mailto:kratochanna@gmail.com>__>
        wrote:

             Hi,

             On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
        <wenzeslaus@gmail.com <mailto:wenzeslaus@gmail.com>
             <mailto:wenzeslaus@gmail.com
        <mailto:wenzeslaus@gmail.com>>> wrote:

                 On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
                 <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
                 <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 10:38, Paulo van Breugel wrote:

                         On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                         <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
                         <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>
                         <mailto:mlennert@club.
        <mailto:mlennert@club.>__worldo__nline.be <http://worldonline.be>

                         <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>>> wrote:

                              On 14/10/14 09:14, Paulo van Breugel wrote:

                                  Putting the 'ignore' option in
        separate tab
                         with patterns is fine I
                                  think. Also, for g.remove to have the
        'type'
                         and 'name' together
                                  in one
                                  tab is also a good idea imho.

                                  I am not sure I understand the last
        question;
                         you mean to add the
                                  possibility to make an option required but
                         still have the option
                                  to put
                                  it in another section? I think that
        would be a
                         good idea, not
                                  only in
                                  this case, but more in general, it
        would make
                         it easier to create an
                                  consistent interface for modules that
        require
                         more than a few
                                  inputs.
                                  It might be a good idea to flag options as
                         required, e.g., by adding
                                  '(required)' after the option name?

                              I'm not sure I agree with this as this
        would leave
                         the door open for
                              required flags to be disseminated across
        several
                         sections. I like
                              the fact that the use immediately sees what is
                         required to run the
                              module.

                         I guess it is a matter of preference. There are
        some
                         grey area or cases
                         where this separate 'required' tab does not
        really work
                         i.m.h.o.

                         The '-f' flag in g.remove is one example. You
        can run
                         the module without
                         (so it shouldn't go in the 'required' tab), but you
                         can't do what the
                         module is basically meant to do without it,
        which is
                         removing layers (so
                         in that sense it should be a required choice).

                         Perhaps a better example is r.random. One of the
                         required options is the
                         output layer. That can be a raster layer, a
        vector layer
                         or both.
                         Because of this construct, the required output name
                         cannot be marked as
                         required. Solution is to use a separate tab
        'optional'
                         where the user
                         can provide the output name of the vector,
        raster or
                         both layers. So the
                         user has to fill in required information in a
        'required
                         tab' and an
                         'optional' tab. I don't think it is really
        problematic
                         as failing to
                         give the output name results in a clear error
        message,
                         but it isn't
                         exactly consistent.

                     The new options to declare parameters as mutually
        exclusive
                     or as "at least one is requried of the group" might
        be a
                     solution to that, but no idea how to implement this
        in the GUI.

                 Put this to GUI is certainly needed but challenging and
        I it
                 will not be included in 7.0. Perhaps we should put this
        to the
                 manual in some way. But modules are not using it anyway.

                 Anyway, these "at least one required" are causing Required
                 section to be less and less used, so that's another
        reason why
                 it makes sense to leave it out sometimes.

             I think it makes thanks to 'override' the required property
        with the
             guisection. If we do it for a module, we should make sure
        there is
             no Required tab at all. I think having required parameters
        in custom
             tabs and eliminate Required tab is totally fine. Having
        Required tab
             and at the same time have required parameters in other sections
             would not work well.

             Also we could mark the required options in the gui somehow, for
             example add a red star? In the code I see attempts to
        render the
             labels as bold, it is not used eventually, but I don't
        think bold is
             the best way anyway.

        I attached screenshots with using the red star for required
        options (and
        in this case I was also testing when the guisection is preferred to
        required). In my opinion, it gives you good idea what is required or
        not. There are some problems coming from the wxPython
        limitations, for
        example the one which you see on the second screenshot: when the
        label
        is part of the border, I can't set the asterisk red, the color
        can be
        changed only for the entire label. But for majority options, it
        works.

        Regarding the required vs. guisection, I really think we should
        try to
        organize the options logically, not based on required/optional. Some
        distinction of the required options is then needed and the red
        asterisk
        seems to be a good solution. But we can discuss some other
        options too,
        of course.

    If you really want to go down that path (it would get a 0 from me),
    then please remove the required tab completely. It will be very
    confusing to have a required section, but not with all required
    parameters in it.

    I personally like the way the required tab focuses attention on the
    most important parameters, even though I do understand that there
    are ambiguities that this system creates. I'm not sure, though, that
    getting rid of the required tab is the solution. But if you go in
    that direction it should be all the way.

Well, there are already modules which already don't have required tab
(r.colors, many t.* modules). Also a lot of modules have required tab
but it is more confusing than helpful. Do you require to remove Required
tab from all the modules? Even from modules where it still makes sense?
Or you are talking about the case when the option is required but the
guisection is specified, so it would get into a different tab? For the
first option, we would have to go through all modules (several hundreds)
and come up with some substitute, that's not feasible.

No, I agree with what Vaclav said: for those modules where required options are all in the required section, this should stay. However, if in a module you put required parameters in other sections, then there should be no more required section for that module.

Moritz

[annakrat]

On Tue, Oct 28, 2014 at 1:38 PM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 28/10/14 16:40, Anna Petrášová wrote:

On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 25/10/14 02:58, Anna Petrášová wrote:

        Hi,

        On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová
        <kratochanna@gmail.com <mailto:kratochanna@gmail.com>
        <mailto:kratochanna@gmail.com>__>
        wrote:

             Hi,

             On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
        <wenzeslaus@gmail.com <mailto:wenzeslaus@gmail.com>
             <mailto:wenzeslaus@gmail.com
        <mailto:wenzeslaus@gmail.com>>> wrote:

                 On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
                 <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
                 <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 10:38, Paulo van Breugel wrote:

                         On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                         <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
                         <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>
                         <mailto:mlennert@club.
        <mailto:mlennert@club.>__worldo__nline.be <http://worldonline.be>

                         <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>>> wrote:

                              On 14/10/14 09:14, Paulo van Breugel wrote:

                                  Putting the 'ignore' option in
        separate tab
                         with patterns is fine I
                                  think. Also, for g.remove to have the
        'type'
                         and 'name' together
                                  in one
                                  tab is also a good idea imho.

                                  I am not sure I understand the last
        question;
                         you mean to add the
                                  possibility to make an option required
but
                         still have the option
                                  to put
                                  it in another section? I think that
        would be a
                         good idea, not
                                  only in
                                  this case, but more in general, it
        would make
                         it easier to create an
                                  consistent interface for modules that
        require
                         more than a few
                                  inputs.
                                  It might be a good idea to flag options
as
                         required, e.g., by adding
                                  '(required)' after the option name?

                              I'm not sure I agree with this as this
        would leave
                         the door open for
                              required flags to be disseminated across
        several
                         sections. I like
                              the fact that the use immediately sees what
is
                         required to run the
                              module.

                         I guess it is a matter of preference. There are
        some
                         grey area or cases
                         where this separate 'required' tab does not
        really work
                         i.m.h.o.

                         The '-f' flag in g.remove is one example. You
        can run
                         the module without
                         (so it shouldn't go in the 'required' tab), but
you
                         can't do what the
                         module is basically meant to do without it,
        which is
                         removing layers (so
                         in that sense it should be a required choice).

                         Perhaps a better example is r.random. One of the
                         required options is the
                         output layer. That can be a raster layer, a
        vector layer
                         or both.
                         Because of this construct, the required output
name
                         cannot be marked as
                         required. Solution is to use a separate tab
        'optional'
                         where the user
                         can provide the output name of the vector,
        raster or
                         both layers. So the
                         user has to fill in required information in a
        'required
                         tab' and an
                         'optional' tab. I don't think it is really
        problematic
                         as failing to
                         give the output name results in a clear error
        message,
                         but it isn't
                         exactly consistent.

                     The new options to declare parameters as mutually
        exclusive
                     or as "at least one is requried of the group" might
        be a
                     solution to that, but no idea how to implement this
        in the GUI.

                 Put this to GUI is certainly needed but challenging and
        I it
                 will not be included in 7.0. Perhaps we should put this
        to the
                 manual in some way. But modules are not using it anyway.

                 Anyway, these "at least one required" are causing
Required
                 section to be less and less used, so that's another
        reason why
                 it makes sense to leave it out sometimes.

             I think it makes thanks to 'override' the required property
        with the
             guisection. If we do it for a module, we should make sure
        there is
             no Required tab at all. I think having required parameters
        in custom
             tabs and eliminate Required tab is totally fine. Having
        Required tab
             and at the same time have required parameters in other
sections
             would not work well.

             Also we could mark the required options in the gui somehow,
for
             example add a red star? In the code I see attempts to
        render the
             labels as bold, it is not used eventually, but I don't
        think bold is
             the best way anyway.

        I attached screenshots with using the red star for required
        options (and
        in this case I was also testing when the guisection is preferred
to
        required). In my opinion, it gives you good idea what is required
or
        not. There are some problems coming from the wxPython
        limitations, for
        example the one which you see on the second screenshot: when the
        label
        is part of the border, I can't set the asterisk red, the color
        can be
        changed only for the entire label. But for majority options, it
        works.

        Regarding the required vs. guisection, I really think we should
        try to
        organize the options logically, not based on required/optional.
Some
        distinction of the required options is then needed and the red
        asterisk
        seems to be a good solution. But we can discuss some other
        options too,
        of course.

    If you really want to go down that path (it would get a 0 from me),
    then please remove the required tab completely. It will be very
    confusing to have a required section, but not with all required
    parameters in it.

    I personally like the way the required tab focuses attention on the
    most important parameters, even though I do understand that there
    are ambiguities that this system creates. I'm not sure, though, that
    getting rid of the required tab is the solution. But if you go in
    that direction it should be all the way.

Well, there are already modules which already don't have required tab
(r.colors, many t.* modules). Also a lot of modules have required tab
but it is more confusing than helpful. Do you require to remove Required
tab from all the modules? Even from modules where it still makes sense?
Or you are talking about the case when the option is required but the
guisection is specified, so it would get into a different tab? For the
first option, we would have to go through all modules (several hundreds)
and come up with some substitute, that's not feasible.

No, I agree with what Vaclav said: for those modules where required
options are all in the required section, this should stay. However, if in a
module you put required parameters in other sections, then there should be
no more required section for that module.

Good, I was not sure. I found a couple of modules which have this problem,
I already tried to reorganize at least the most used ones, will commit it
soon. Some more feedback would be welcome on g.remove layout. Also, I
realized r.horizon would need some better organization of options, but I am
not sure how.

Moritz

[annakrat]

On Tue, Oct 28, 2014 at 3:54 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:

On Tue, Oct 28, 2014 at 1:38 PM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:

On 28/10/14 16:40, Anna Petrášová wrote:

On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert
<mlennert@club.worldonline.be <mailto:mlennert@club.worldonline.be>>
wrote:

    On 25/10/14 02:58, Anna Petrášová wrote:

        Hi,

        On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová
        <kratochanna@gmail.com <mailto:kratochanna@gmail.com>
        <mailto:kratochanna@gmail.com>__>
        wrote:

             Hi,

             On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
        <wenzeslaus@gmail.com <mailto:wenzeslaus@gmail.com>
             <mailto:wenzeslaus@gmail.com
        <mailto:wenzeslaus@gmail.com>>> wrote:

                 On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
                 <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
                 <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>> wrote:

                     On 14/10/14 10:38, Paulo van Breugel wrote:

                         On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
                         <mlennert@club.worldonline.be
        <mailto:mlennert@club.worldonline.be>
                         <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>
                         <mailto:mlennert@club.
        <mailto:mlennert@club.>__worldo__nline.be <http://worldonline.be
>

                         <mailto:mlennert@club.__worldonline.be
        <mailto:mlennert@club.worldonline.be>>>> wrote:

                              On 14/10/14 09:14, Paulo van Breugel wrote:

                                  Putting the 'ignore' option in
        separate tab
                         with patterns is fine I
                                  think. Also, for g.remove to have the
        'type'
                         and 'name' together
                                  in one
                                  tab is also a good idea imho.

                                  I am not sure I understand the last
        question;
                         you mean to add the
                                  possibility to make an option required
but
                         still have the option
                                  to put
                                  it in another section? I think that
        would be a
                         good idea, not
                                  only in
                                  this case, but more in general, it
        would make
                         it easier to create an
                                  consistent interface for modules that
        require
                         more than a few
                                  inputs.
                                  It might be a good idea to flag
options as
                         required, e.g., by adding
                                  '(required)' after the option name?

                              I'm not sure I agree with this as this
        would leave
                         the door open for
                              required flags to be disseminated across
        several
                         sections. I like
                              the fact that the use immediately sees
what is
                         required to run the
                              module.

                         I guess it is a matter of preference. There are
        some
                         grey area or cases
                         where this separate 'required' tab does not
        really work
                         i.m.h.o.

                         The '-f' flag in g.remove is one example. You
        can run
                         the module without
                         (so it shouldn't go in the 'required' tab), but
you
                         can't do what the
                         module is basically meant to do without it,
        which is
                         removing layers (so
                         in that sense it should be a required choice).

                         Perhaps a better example is r.random. One of the
                         required options is the
                         output layer. That can be a raster layer, a
        vector layer
                         or both.
                         Because of this construct, the required output
name
                         cannot be marked as
                         required. Solution is to use a separate tab
        'optional'
                         where the user
                         can provide the output name of the vector,
        raster or
                         both layers. So the
                         user has to fill in required information in a
        'required
                         tab' and an
                         'optional' tab. I don't think it is really
        problematic
                         as failing to
                         give the output name results in a clear error
        message,
                         but it isn't
                         exactly consistent.

                     The new options to declare parameters as mutually
        exclusive
                     or as "at least one is requried of the group" might
        be a
                     solution to that, but no idea how to implement this
        in the GUI.

                 Put this to GUI is certainly needed but challenging and
        I it
                 will not be included in 7.0. Perhaps we should put this
        to the
                 manual in some way. But modules are not using it anyway.

                 Anyway, these "at least one required" are causing
Required
                 section to be less and less used, so that's another
        reason why
                 it makes sense to leave it out sometimes.

             I think it makes thanks to 'override' the required property
        with the
             guisection. If we do it for a module, we should make sure
        there is
             no Required tab at all. I think having required parameters
        in custom
             tabs and eliminate Required tab is totally fine. Having
        Required tab
             and at the same time have required parameters in other
sections
             would not work well.

             Also we could mark the required options in the gui somehow,
for
             example add a red star? In the code I see attempts to
        render the
             labels as bold, it is not used eventually, but I don't
        think bold is
             the best way anyway.

        I attached screenshots with using the red star for required
        options (and
        in this case I was also testing when the guisection is preferred
to
        required). In my opinion, it gives you good idea what is
required or
        not. There are some problems coming from the wxPython
        limitations, for
        example the one which you see on the second screenshot: when the
        label
        is part of the border, I can't set the asterisk red, the color
        can be
        changed only for the entire label. But for majority options, it
        works.

        Regarding the required vs. guisection, I really think we should
        try to
        organize the options logically, not based on required/optional.
Some
        distinction of the required options is then needed and the red
        asterisk
        seems to be a good solution. But we can discuss some other
        options too,
        of course.

    If you really want to go down that path (it would get a 0 from me),
    then please remove the required tab completely. It will be very
    confusing to have a required section, but not with all required
    parameters in it.

    I personally like the way the required tab focuses attention on the
    most important parameters, even though I do understand that there
    are ambiguities that this system creates. I'm not sure, though, that
    getting rid of the required tab is the solution. But if you go in
    that direction it should be all the way.

Well, there are already modules which already don't have required tab
(r.colors, many t.* modules). Also a lot of modules have required tab
but it is more confusing than helpful. Do you require to remove Required
tab from all the modules? Even from modules where it still makes sense?
Or you are talking about the case when the option is required but the
guisection is specified, so it would get into a different tab? For the
first option, we would have to go through all modules (several hundreds)
and come up with some substitute, that's not feasible.

No, I agree with what Vaclav said: for those modules where required
options are all in the required section, this should stay. However, if in a
module you put required parameters in other sections, then there should be
no more required section for that module.

Good, I was not sure. I found a couple of modules which have this problem,
I already tried to reorganize at least the most used ones, will commit it
soon. Some more feedback would be welcome on g.remove layout. Also, I
realized r.horizon would need some better organization of options, but I am
not sure how.

Some changes done in r62466.

Moritz

[ecodiv]

Whoever creates/maintains a module can of course always decide whether to use a tab with the name ‘required’. A question is what would you want to happens if you write an addon and mark on option as ‘required’. Now it goes to the ‘required’ tab. The suggested alternative was that it gets marked by a red star, but it is up to the creator of the script to decide to what tab it goes? So these options can still go into a ‘required’ tab (don’t know how implementing this impacts existing modules, I guess you don’t want to do this manually for all existing modules)

···

On 28-10-14 18:38, Moritz Lennert wrote:

On 28/10/14 16:40, Anna Petrášová wrote:

On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert
<mlennert@club.worldonline.be mailto:mlennert@club.worldonline.be> wrote:

On 25/10/14 02:58, Anna Petrášová wrote:

Hi,

On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová
<kratochanna@gmail.com mailto:kratochanna@gmail.com
<mailto:kratochanna@gmail.com mailto:kratochanna@gmail.com>__>
wrote:

Hi,

On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
<wenzeslaus@gmail.com mailto:wenzeslaus@gmail.com
<mailto:wenzeslaus@gmail.com
mailto:wenzeslaus@gmail.com>> wrote:

On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
<mlennert@club.worldonline.be
mailto:mlennert@club.worldonline.be
<mailto:mlennert@club.__worldonline.be
mailto:mlennert@club.worldonline.be>> wrote:

On 14/10/14 10:38, Paulo van Breugel wrote:

On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<mlennert@club.worldonline.be
mailto:mlennert@club.worldonline.be
<mailto:mlennert@club.__worldonline.be
mailto:mlennert@club.worldonline.be>
<mailto:mlennert@club.
mailto:mlennert@club.__worldo__nline.be http://worldonline.be

<mailto:mlennert@club.__worldonline.be
mailto:mlennert@club.worldonline.be>>> wrote:

On 14/10/14 09:14, Paulo van Breugel wrote:

Putting the ‘ignore’ option in
separate tab
with patterns is fine I
think. Also, for g.remove to have the
‘type’
and ‘name’ together
in one
tab is also a good idea imho.

I am not sure I understand the last
question;
you mean to add the
possibility to make an option required but
still have the option
to put
it in another section? I think that
would be a
good idea, not
only in
this case, but more in general, it
would make
it easier to create an
consistent interface for modules that
require
more than a few
inputs.
It might be a good idea to flag options as
required, e.g., by adding
‘(required)’ after the option name?

I’m not sure I agree with this as this
would leave
the door open for
required flags to be disseminated across
several
sections. I like
the fact that the use immediately sees what is
required to run the
module.

I guess it is a matter of preference. There are
some
grey area or cases
where this separate ‘required’ tab does not
really work
i.m.h.o.

The ‘-f’ flag in g.remove is one example. You
can run
the module without
(so it shouldn’t go in the ‘required’ tab), but you
can’t do what the
module is basically meant to do without it,
which is
removing layers (so
in that sense it should be a required choice).

Perhaps a better example is r.random. One of the
required options is the
output layer. That can be a raster layer, a
vector layer
or both.
Because of this construct, the required output name
cannot be marked as
required. Solution is to use a separate tab
‘optional’
where the user
can provide the output name of the vector,
raster or
both layers. So the
user has to fill in required information in a
‘required
tab’ and an
‘optional’ tab. I don’t think it is really
problematic
as failing to
give the output name results in a clear error
message,
but it isn’t
exactly consistent.

The new options to declare parameters as mutually
exclusive
or as “at least one is requried of the group” might
be a
solution to that, but no idea how to implement this
in the GUI.

Put this to GUI is certainly needed but challenging and
I it
will not be included in 7.0. Perhaps we should put this
to the
manual in some way. But modules are not using it anyway.

Anyway, these “at least one required” are causing Required
section to be less and less used, so that’s another
reason why
it makes sense to leave it out sometimes.

I think it makes thanks to ‘override’ the required property
with the
guisection. If we do it for a module, we should make sure
there is
no Required tab at all. I think having required parameters
in custom
tabs and eliminate Required tab is totally fine. Having
Required tab
and at the same time have required parameters in other sections
would not work well.

Also we could mark the required options in the gui somehow, for
example add a red star? In the code I see attempts to
render the
labels as bold, it is not used eventually, but I don’t
think bold is
the best way anyway.

I attached screenshots with using the red star for required
options (and
in this case I was also testing when the guisection is preferred to
required). In my opinion, it gives you good idea what is required or
not. There are some problems coming from the wxPython
limitations, for
example the one which you see on the second screenshot: when the
label
is part of the border, I can’t set the asterisk red, the color
can be
changed only for the entire label. But for majority options, it
works.

Regarding the required vs. guisection, I really think we should
try to
organize the options logically, not based on required/optional. Some
distinction of the required options is then needed and the red
asterisk
seems to be a good solution. But we can discuss some other
options too,
of course.

If you really want to go down that path (it would get a 0 from me),
then please remove the required tab completely. It will be very
confusing to have a required section, but not with all required
parameters in it.

I personally like the way the required tab focuses attention on the
most important parameters, even though I do understand that there
are ambiguities that this system creates. I’m not sure, though, that
getting rid of the required tab is the solution. But if you go in
that direction it should be all the way.

Well, there are already modules which already don’t have required tab
(r.colors, many t.* modules). Also a lot of modules have required tab
but it is more confusing than helpful. Do you require to remove Required
tab from all the modules? Even from modules where it still makes sense?
Or you are talking about the case when the option is required but the
guisection is specified, so it would get into a different tab? For the
first option, we would have to go through all modules (several hundreds)
and come up with some substitute, that’s not feasible.

No, I agree with what Vaclav said: for those modules where required options are all in the required section, this should stay. However, if in a module you put required parameters in other sections, then there should be no more required section for that module.

Moritz