On Tue, Oct 28, 2014 at 1:38 PM, Moritz Lennert < [email protected]> wrote:
> On 28/10/14 16:40, Anna Petrášová wrote: > >> >> >> On Tue, Oct 28, 2014 at 10:31 AM, Moritz Lennert >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> On 25/10/14 02:58, Anna Petrášová wrote: >> >> Hi, >> >> On Tue, Oct 14, 2014 at 11:56 AM, Anna Petrášová >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>__> >> wrote: >> >> Hi, >> >> On Tue, Oct 14, 2014 at 8:58 AM, Vaclav Petras >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> >> >> >> On Tue, Oct 14, 2014 at 5:28 AM, Moritz Lennert >> <[email protected] >> <mailto:[email protected]> >> <mailto:mlennert@club.__worldonline.be >> <mailto:[email protected]>>> wrote: >> >> On 14/10/14 10:38, Paulo van Breugel wrote: >> >> >> >> On Tue, Oct 14, 2014 at 10:06 AM, Moritz Lennert >> <[email protected] >> <mailto:[email protected]> >> <mailto:mlennert@club.__worldonline.be >> <mailto:[email protected]>> >> <mailto:mlennert@club. >> <mailto:mlennert@club.>__worldo__nline.be <http://worldonline.be> >> >> >> <mailto:mlennert@club.__worldonline.be >> <mailto:[email protected]>>>> 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. >> >> 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. >> >> >> If you really want to go down that path (it would get a 0 from me), >> then please remove the required tab completely. It will be very >> confusing to have a required section, but not with all required >> parameters in it. >> >> I personally like the way the required tab focuses attention on the >> most important parameters, even though I do understand that there >> are ambiguities that this system creates. I'm not sure, though, that >> getting rid of the required tab is the solution. But if you go in >> that direction it should be all the way. >> >> >> Well, there are already modules which already don't have required tab >> (r.colors, many t.* modules). Also a lot of modules have required tab >> but it is more confusing than helpful. Do you require to remove Required >> tab from all the modules? Even from modules where it still makes sense? >> Or you are talking about the case when the option is required but the >> guisection is specified, so it would get into a different tab? For the >> first option, we would have to go through all modules (several hundreds) >> and come up with some substitute, that's not feasible. >> > > 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. 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. > > > Moritz >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
