[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