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

Anna Petrášová kratochanna at gmail.com
Tue Oct 28 12:54:38 PDT 2014

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.

> Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141028/4f205153/attachment-0001.html>

More information about the grass-dev mailing list