<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 1:38 PM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28/10/14 16:40, Anna Petrášová wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert<br></span><span class="">
<<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a> <mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.<u></u>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 href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a> <mailto:<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>><br></span>
<mailto:<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a> <mailto:<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>><u></u>>__><span class=""><br>
wrote:<br>
<br>
Hi,<br>
<br>
On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras<br>
<<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a> <mailto:<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>><br></span>
<mailto:<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a><span class=""><br>
<mailto:<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>>><u></u>> wrote:<br>
<br>
<br>
<br>
On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert<br>
<<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a><br>
<mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.<u></u>worldonline.be</a>><br></span><span class="">
<mailto:<a href="mailto:mlennert@club." target="_blank">mlennert@club.</a>__<a href="http://worldonline.be" target="_blank">worldo<u></u>nline.be</a><br>
<mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.<u></u>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 href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a><br>
<mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.<u></u>worldonline.be</a>><br>
<mailto:<a href="mailto:mlennert@club." target="_blank">mlennert@club.</a>__<a href="http://worldonline.be" target="_blank">worldo<u></u>nline.be</a><br>
<mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.<u></u>worldonline.be</a>>><br></span>
<mailto:<a href="mailto:mlennert@club" target="_blank">mlennert@club</a>.<br>
<mailto:<a href="mailto:mlennert@club" target="_blank">mlennert@club</a>.>__<a href="http://worldo__nline.be" target="_blank">world<u></u>o__nline.be</a> <<a href="http://worldonline.be" target="_blank">http://worldonline.be</a>><div><div class="h5"><br>
<br>
<mailto:<a href="mailto:mlennert@club." target="_blank">mlennert@club.</a>__<a href="http://worldonline.be" target="_blank">worldo<u></u>nline.be</a><br>
<mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.<u></u>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>
</div></div></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.</blockquote><div><br></div><div>Good, I was not sure. I found a couple of modules which have this problem, I already tried to reorganize at least the most used ones, will commit it soon. Some more feedback would be welcome on g.remove layout. Also, I realized r.horizon would need some better organization of options, but I am not sure how.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Moritz<br>
</font></span></blockquote></div><br></div></div>