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

Paulo van Breugel p.vanbreugel at gmail.com
Sat Oct 25 01:55:11 PDT 2014 

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

> Hi,
>
> On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratochanna at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzeslaus at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert <
>>> mlennert at 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 at club.worldonline.be <mailto:mlennert at 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 at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141025/a437557b/attachment.html>

More information about the grass-dev mailing list