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


On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<[email protected] <mailto:[email protected]>> 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

_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to