<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000099">
<br>
<div class="moz-cite-prefix">On 28-10-14 18:38, Moritz Lennert
wrote:<br>
</div>
<blockquote cite="mid:544FD47F.7010108@club.worldonline.be"
type="cite">On 28/10/14 16:40, Anna Petrášová wrote:
<br>
<blockquote type="cite">
<br>
<br>
On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert
<br>
<<a class="moz-txt-link-abbreviated" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>> wrote:
<br>
<br>
On 25/10/14 02:58, Anna Petrášová wrote:
<br>
<br>
Hi,
<br>
<br>
On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová
<br>
<<a class="moz-txt-link-abbreviated" href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:kratochanna@gmail.com"><mailto:kratochanna@gmail.com></a>
<br>
<<a class="moz-txt-link-freetext" href="mailto:kratochanna@gmail.com">mailto:kratochanna@gmail.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:kratochanna@gmail.com"><mailto:kratochanna@gmail.com></a>>__>
<br>
wrote:
<br>
<br>
Hi,
<br>
<br>
On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras
<br>
<<a class="moz-txt-link-abbreviated" href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:wenzeslaus@gmail.com"><mailto:wenzeslaus@gmail.com></a>
<br>
<<a class="moz-txt-link-freetext" href="mailto:wenzeslaus@gmail.com">mailto:wenzeslaus@gmail.com</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:wenzeslaus@gmail.com"><mailto:wenzeslaus@gmail.com></a>>> wrote:
<br>
<br>
<br>
<br>
On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert
<br>
<<a class="moz-txt-link-abbreviated" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>
<br>
<<a class="moz-txt-link-freetext" href="mailto:mlennert@club.__worldonline.be">mailto:mlennert@club.__worldonline.be</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>>>
wrote:
<br>
<br>
On 14/10/14 10:38, Paulo van Breugel wrote:
<br>
<br>
<br>
<br>
On Tue, Oct 14, 2014 at 10:06 AM,
Moritz Lennert
<br>
<<a class="moz-txt-link-abbreviated" href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>
<br>
<<a class="moz-txt-link-freetext" href="mailto:mlennert@club.__worldonline.be">mailto:mlennert@club.__worldonline.be</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>>
<br>
<<a class="moz-txt-link-freetext" href="mailto:mlennert@club">mailto:mlennert@club</a>.
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club."><mailto:mlennert@club.></a>__worldo__nline.be
<a class="moz-txt-link-rfc2396E" href="http://worldonline.be"><http://worldonline.be></a>
<br>
<br>
<<a class="moz-txt-link-freetext" href="mailto:mlennert@club.__worldonline.be">mailto:mlennert@club.__worldonline.be</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:mlennert@club.worldonline.be"><mailto:mlennert@club.worldonline.be></a>>>>
wrote:
<br>
<br>
On 14/10/14 09:14, Paulo van
Breugel wrote:
<br>
<br>
Putting the 'ignore' option in
<br>
separate tab
<br>
with patterns is fine I
<br>
think. Also, for g.remove to
have the
<br>
'type'
<br>
and 'name' together
<br>
in one
<br>
tab is also a good idea imho.
<br>
<br>
I am not sure I understand the
last
<br>
question;
<br>
you mean to add the
<br>
possibility to make an option
required but
<br>
still have the option
<br>
to put
<br>
it in another section? I think
that
<br>
would be a
<br>
good idea, not
<br>
only in
<br>
this case, but more in
general, it
<br>
would make
<br>
it easier to create an
<br>
consistent interface for
modules that
<br>
require
<br>
more than a few
<br>
inputs.
<br>
It might be a good idea to
flag options as
<br>
required, e.g., by adding
<br>
'(required)' after the option
name?
<br>
<br>
<br>
I'm not sure I agree with this as
this
<br>
would leave
<br>
the door open for
<br>
required flags to be disseminated
across
<br>
several
<br>
sections. I like
<br>
the fact that the use immediately
sees what is
<br>
required to run the
<br>
module.
<br>
<br>
<br>
I guess it is a matter of preference.
There are
<br>
some
<br>
grey area or cases
<br>
where this separate 'required' tab does
not
<br>
really work
<br>
i.m.h.o.
<br>
<br>
The '-f' flag in g.remove is one
example. You
<br>
can run
<br>
the module without
<br>
(so it shouldn't go in the 'required'
tab), but you
<br>
can't do what the
<br>
module is basically meant to do without
it,
<br>
which is
<br>
removing layers (so
<br>
in that sense it should be a required
choice).
<br>
<br>
Perhaps a better example is r.random.
One of the
<br>
required options is the
<br>
output layer. That can be a raster
layer, a
<br>
vector layer
<br>
or both.
<br>
Because of this construct, the required
output name
<br>
cannot be marked as
<br>
required. Solution is to use a separate
tab
<br>
'optional'
<br>
where the user
<br>
can provide the output name of the
vector,
<br>
raster or
<br>
both layers. So the
<br>
user has to fill in required
information in a
<br>
'required
<br>
tab' and an
<br>
'optional' tab. I don't think it is
really
<br>
problematic
<br>
as failing to
<br>
give the output name results in a clear
error
<br>
message,
<br>
but it isn't
<br>
exactly consistent.
<br>
<br>
<br>
The new options to declare parameters as
mutually
<br>
exclusive
<br>
or as "at least one is requried of the
group" might
<br>
be a
<br>
solution to that, but no idea how to
implement this
<br>
in the GUI.
<br>
<br>
Put this to GUI is certainly needed but
challenging and
<br>
I it
<br>
will not be included in 7.0. Perhaps we should
put this
<br>
to the
<br>
manual in some way. But modules are not using
it anyway.
<br>
<br>
Anyway, these "at least one required" are
causing Required
<br>
section to be less and less used, so that's
another
<br>
reason why
<br>
it makes sense to leave it out sometimes.
<br>
<br>
<br>
I think it makes thanks to 'override' the required
property
<br>
with the
<br>
guisection. If we do it for a module, we should
make sure
<br>
there is
<br>
no Required tab at all. I think having required
parameters
<br>
in custom
<br>
tabs and eliminate Required tab is totally fine.
Having
<br>
Required tab
<br>
and at the same time have required parameters in
other sections
<br>
would not work well.
<br>
<br>
<br>
Also we could mark the required options in the gui
somehow, for
<br>
example add a red star? In the code I see attempts
to
<br>
render the
<br>
labels as bold, it is not used eventually, but I
don't
<br>
think bold is
<br>
the best way anyway.
<br>
<br>
<br>
I attached screenshots with using the red star for
required
<br>
options (and
<br>
in this case I was also testing when the guisection is
preferred to
<br>
required). In my opinion, it gives you good idea what is
required or
<br>
not. There are some problems coming from the wxPython
<br>
limitations, for
<br>
example the one which you see on the second screenshot:
when the
<br>
label
<br>
is part of the border, I can't set the asterisk red, the
color
<br>
can be
<br>
changed only for the entire label. But for majority
options, it
<br>
works.
<br>
<br>
Regarding the required vs. guisection, I really think we
should
<br>
try to
<br>
organize the options logically, not based on
required/optional. Some
<br>
distinction of the required options is then needed and
the red
<br>
asterisk
<br>
seems to be a good solution. But we can discuss some
other
<br>
options too,
<br>
of course.
<br>
<br>
<br>
If you really want to go down that path (it would get a 0
from me),
<br>
then please remove the required tab completely. It will be
very
<br>
confusing to have a required section, but not with all
required
<br>
parameters in it.
<br>
<br>
I personally like the way the required tab focuses attention
on the
<br>
most important parameters, even though I do understand that
there
<br>
are ambiguities that this system creates. I'm not sure,
though, that
<br>
getting rid of the required tab is the solution. But if you
go in
<br>
that direction it should be all the way.
<br>
<br>
<br>
Well, there are already modules which already don't have
required tab
<br>
(r.colors, many t.* modules). Also a lot of modules have
required tab
<br>
but it is more confusing than helpful. Do you require to remove
Required
<br>
tab from all the modules? Even from modules where it still makes
sense?
<br>
Or you are talking about the case when the option is required
but the
<br>
guisection is specified, so it would get into a different tab?
For the
<br>
first option, we would have to go through all modules (several
hundreds)
<br>
and come up with some substitute, that's not feasible.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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)<br>
<br>
<blockquote cite="mid:544FD47F.7010108@club.worldonline.be"
type="cite">
<br>
Moritz
<br>
</blockquote>
<br>
</body>
</html>