On Tue, Oct 28, 2014 at 3:54 PM, Anna Petrášová <[email protected]> wrote:
> > > 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. > Some changes done in r62466. > >> >> Moritz >> > >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
