[GRASS-dev] No Required GUI section for g.list and g.remove
Anna Petrášová
kratochanna at gmail.com
Tue Oct 28 17:28:00 PDT 2014
On Tue, Oct 28, 2014 at 3:54 PM, Anna Petrášová <kratochanna at gmail.com>
wrote:
>
>
> On Tue, Oct 28, 2014 at 1:38 PM, Moritz Lennert <
> mlennert at 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 at club.worldonline.be <mailto:mlennert at 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 at gmail.com <mailto:kratochanna at gmail.com>
>>> <mailto:kratochanna at gmail.com <mailto:kratochanna at gmail.com>>__>
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
>>> <wenzeslaus at gmail.com <mailto:wenzeslaus at gmail.com>
>>> <mailto:wenzeslaus at gmail.com
>>> <mailto:wenzeslaus at gmail.com>>> wrote:
>>>
>>>
>>>
>>> On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
>>> <mlennert at club.worldonline.be
>>> <mailto:mlennert at club.worldonline.be>
>>> <mailto:mlennert at club.__worldonline.be
>>> <mailto: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>
>>> <mailto:mlennert at club.__worldonline.be
>>> <mailto:mlennert at club.worldonline.be>>
>>> <mailto:mlennert at club.
>>> <mailto:mlennert at club.>__worldo__nline.be <http://worldonline.be
>>> >
>>>
>>>
>>> <mailto: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.
>>>
>>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141028/86b6e370/attachment-0001.html>
More information about the grass-dev
mailing list