<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 25, 2014 at 4:55 AM, Paulo van Breugel <span dir="ltr"><<a href="mailto:p.vanbreugel@gmail.com" target="_blank">p.vanbreugel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Oct 25, 2014 at 2:58 AM, Anna Petrášová <span dir="ltr"><<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <span dir="ltr"><<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Oct 14, 2014 at 5:28 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 14/10/14 10:38, Paulo van Breugel wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<br>
<br>
On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert<br></span><div><div>
<<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 14/10/14 09:14, Paulo van Breugel wrote:<br>
<br>
Putting the 'ignore' option in separate tab with patterns is fine I<br>
think. Also, for g.remove to have the 'type' and 'name' together<br>
in one<br>
tab is also a good idea imho.<br>
<br>
I am not sure I understand the last question; you mean to add the<br>
possibility to make an option required but still have the option<br>
to put<br>
it in another section? I think that would be a good idea, not<br>
only in<br>
this case, but more in general, it would make it easier to create an<br>
consistent interface for modules that require more than a few<br>
inputs.<br>
It might be a good idea to flag options as required, e.g., by adding<br>
'(required)' after the option name?<br>
<br>
<br>
I'm not sure I agree with this as this would leave the door open for<br>
required flags to be disseminated across several sections. I like<br>
the fact that the use immediately sees what is required to run the<br>
module.<br>
<br>
<br>
I guess it is a matter of preference. There are some grey area or cases<br>
where this separate 'required' tab does not really work i.m.h.o.<br>
<br>
The '-f' flag in g.remove is one example. You can run the module without<br>
(so it shouldn't go in the 'required' tab), but you can't do what the<br>
module is basically meant to do without it, which is 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 required options is the<br>
output layer. That can be a raster layer, a vector layer or both.<br>
Because of this construct, the required output name cannot be marked as<br>
required. Solution is to use a separate tab 'optional' where the user<br>
can provide the output name of the vector, raster or both layers. So the<br>
user has to fill in required information in a 'required tab' and an<br>
'optional' tab. I don't think it is really problematic as failing to<br>
give the output name results in a clear error message, but it isn't<br>
exactly consistent.<br>
</div></div></blockquote>
<br>
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.<br>
<br></blockquote></div></div><div>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.<br><br>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.<br></div></div></div></div></blockquote><div><br></div></div></div><div>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.</div><div><br></div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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. </div></div></div></div></blockquote><div><br></div></div></div><div>This is excellent. Red stars are nice but even in grey it works fine. It is a fairly common practise to mark required options / entries this way so this will probably work for most users<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div></span><div>I totally agree, I think this is the way to go. <br></div></div></div></div></blockquote><div><br></div><div><br></div><div>I committed it in r62403. I will have to adjust guisections in several modules to reflect the changes.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> Anna</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>Anna</div></font></span><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If we want to go a simpler road, I think I would be more in favour of allowing some optional parameters in the required section (but marking them clearly as optional), than to move any required parameters to other sections than 'Required'.<div><div><br></div></div></blockquote></span><div>I think that the opposite is true. Having 'optional' in Required section would defeat the purpose of Required section. And if we consider that options which are in group "one of them required" are spread in other sections than Required, then putting standard 'required' options to other sections is nothing new.<br><br>And yes, we need to go a simpler road for now.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Vaclav<br></div></font></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
<br>
Moritz<br>
<br>
______________________________<u></u>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>