On 25/10/14 02:58, Anna Petrášová wrote:
Hi,
On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <[email protected]
<mailto:[email protected]>> wrote:
Hi,
On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <[email protected]
<mailto:[email protected]>> wrote:
On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
<[email protected]
<mailto:[email protected]>> wrote:
On 14/10/14 10:38, Paulo van Breugel wrote:
On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert
<[email protected]
<mailto:[email protected]>
<mailto:mlennert@club.__worldonline.be
<mailto:[email protected]>>> 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.
Moritz
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
