[GRASS-dev] No Required GUI section for g.list and g.remove
Moritz Lennert
mlennert at club.worldonline.be
Tue Oct 28 10:38:07 PDT 2014
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.
Moritz
More information about the grass-dev
mailing list