[GRASS-dev] No Required GUI section for g.list and g.remove
Paulo van Breugel
p.vanbreugel at gmail.com
Wed Oct 29 01:50:07 PDT 2014
On 28-10-14 18:38, Moritz Lennert 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.
Whoever creates/maintains a module can of course always decide whether
to use a tab with the name 'required'. A question is what would you want
to happens if you write an addon and mark on option as 'required'. Now
it goes to the 'required' tab. The suggested alternative was that it
gets marked by a red star, but it is up to the creator of the script to
decide to what tab it goes? So these options can still go into a
'required' tab (don't know how implementing this impacts existing
modules, I guess you don't want to do this manually for all existing
modules)
>
> Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141029/64d71b57/attachment-0001.html>
More information about the grass-dev
mailing list