On Sat, Oct 25, 2014 at 2:58 AM, Anna Petrášová <kratocha...@gmail.com> wrote:
> Hi, > > On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová <kratocha...@gmail.com> > wrote: > >> Hi, >> >> On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras <wenzesl...@gmail.com> >> wrote: >> >>> >>> >>> On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert < >>> 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>> >>>>> 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. > 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 > > 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. > I totally agree, I think this is the way to go. > > Anna > > > >> Anna >> >> >>> >>>> 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'. >>>> >>>> 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. >>> >>> And yes, we need to go a simpler road for now. >>> >>> Vaclav >>> >>>> >>>> Moritz >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>>> >>> >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> >> >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev