On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert
<mlenn...@club.worldonline.be <mailto:mlenn...@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á
<kratocha...@gmail.com <mailto:kratocha...@gmail.com>
<mailto:kratocha...@gmail.com <mailto:kratocha...@gmail.com>>__>
wrote:
Hi,
On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
<wenzesl...@gmail.com <mailto:wenzesl...@gmail.com>
<mailto:wenzesl...@gmail.com
<mailto:wenzesl...@gmail.com>>> wrote:
On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
<mlenn...@club.worldonline.be
<mailto:mlenn...@club.worldonline.be>
<mailto:mlennert@club.__worldonline.be
<mailto:mlenn...@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
<mlenn...@club.worldonline.be
<mailto:mlenn...@club.worldonline.be>
<mailto:mlennert@club.__worldonline.be
<mailto:mlenn...@club.worldonline.be>>
<mailto:mlennert@club.
<mailto:mlennert@club.>__worldo__nline.be
<http://worldonline.be>
<mailto:mlennert@club.__worldonline.be
<mailto:mlenn...@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.
