<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 3:54 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 28/10/14 16:40, Anna Petrášová wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<br>
<br>
On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert<br></span><span>
<<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><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><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>
                 <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><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></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></div></div></div></blockquote><div><br></div><div>Some changes done in r62466.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font color="#888888"><br>
<br>
Moritz<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div>