<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000099">
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.<br>
<br>
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?<br>
<br>
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. <br>
<br>
Paulo<br>
<br>
<br>
<div class="moz-cite-prefix">On 14-10-14 04:17, Vaclav Petras wrote:<br>
</div>
<blockquote
cite="mid:CABo5uVt2BEDRf3doNZgLGi=idoieAX1jg--PYGAGhVs4BBhpBw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi,<br>
<br>
</div>
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.<br>
<br>
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.<br>
<div>
<div><br>
</div>
<div>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).<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Thanks for your opinions,<br>
</div>
<div>Vaclav<br>
</div>
<div><br>
r62248 <a moz-do-not-send="true"
href="http://trac.osgeo.org/grass/changeset/62248">http://trac.osgeo.org/grass/changeset/62248</a><br>
#2440 <a moz-do-not-send="true"
href="http://trac.osgeo.org/grass/ticket/2440">http://trac.osgeo.org/grass/ticket/2440</a><br>
#2437 <a moz-do-not-send="true"
href="http://trac.osgeo.org/grass/ticket/2437">http://trac.osgeo.org/grass/ticket/2437</a><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
grass-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></pre>
</blockquote>
<br>
</body>
</html>