On Sat, Oct 25, 2014 at 4:55 AM, Paulo van Breugel <p.vanbreu...@gmail.com> wrote:
> > 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. > I committed it in r62403. I will have to adjust guisections in several modules to reflect the changes. > >> 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