[GRASS-dev] No Required GUI section for g.list and g.remove
Anna Petrášová
kratochanna at gmail.com
Sun Oct 26 18:42:46 PDT 2014
On Sat, Oct 25, 2014 at 4:55 AM, Paulo van Breugel <p.vanbreugel at gmail.com>
wrote:
>
> 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.
>
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 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/20141026/2c8f6add/attachment-0001.html>
More information about the grass-dev
mailing list