[GRASS-dev] No Required GUI section for g.list and g.remove

Paulo van Breugel p.vanbreugel at gmail.com
Tue Oct 14 00:14:25 PDT 2014


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?

On a side note, why the -f flag of g.remove  is in the 'optional' tab? I 
understand it is optional, but as you noted, it is a primary option.. it 
is essential to do what the function is suppose to do, remove layers. As 
a new user I would not expect such an essential option in the optional 
tab I think.

Paulo


On 14-10-14 04:17, Vaclav Petras wrote:
> Hi,
>
> Anna and I discussed the GUI sections of g.list and g.remove. The 
> changes are now in trunk (r62248). However, few issues still remain.
>
> It seems to us that although `names` and `ignore` in g.remove are 
> similar from the point of view of implementation, they have completely 
> different use case. While `names` is here to provide a simple 
> interface, `ignore` extends the interface which is using patterns. So, 
> non-advanced user using GUI will surely want `names` but not `ignore` 
> and GUI should reflect this. Thus `ignore` should probably go to 
> Pattern (although it is not 100% consistent) and `names` to some basic 
> category.
>
> Also, Required section (of both g.remove and g.list) contains just one 
> item - `type`. In case of g.remove, it could make sense to have the 
> `names` together with `type` in some Basic section which would be the 
> primary section users can focus on (besides approval by -f in 
> Optional). This of course expects that no elements will be added to 
> the `type` list (#2440, #2437).
>
> So, the big question is if we want to allow Required section to be 
> overridden by another section if it is provided. Currently if option 
> is required, GUI puts it into Required section no matter if another 
> GUI section was specified.
>
> Thanks for your opinions,
> Vaclav
>
> r62248 http://trac.osgeo.org/grass/changeset/62248
> #2440 http://trac.osgeo.org/grass/ticket/2440
> #2437 http://trac.osgeo.org/grass/ticket/2437
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141014/14fe9c5b/attachment.html>


More information about the grass-dev mailing list