#2437: order parameters in g.remove window
--------------------------------------------------+-------------------------
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Default | Version: unspecified
Keywords: g.list, g.remove, g.mlist, g.mremove | Platform: All
Cpu: Unspecified |
--------------------------------------------------+-------------------------
Changes (by wenzeslaus):
* keywords: g.remove => g.list, g.remove, g.mlist, g.mremove
Comment:
Replying to [comment:13 glynn]:
> Replying to [comment:10 hcho]:
>
> > which can be misleading because it doesn't take multiple pattern
strings, but it only takes multiple map names and a single pattern string.
>
> There seems to be two problems here.
>
> One is that the meaning of pattern=/exclude= may change depending upon
whether -r/-e are used. I thought that we had already learned that making
the semantics of one option change according to the value given for other
options is a bad idea.
>
> The other is that there seems to be confusion over the meaning of
pattern=/exclude= in the absence of -r/-e. Is it a list of map names, or a
glob pattern? It can't be both unless both G_parser() and the GUI
recognise "list of map names or string" as a distinct type. "list of map
names" won't allow the use of glob patterns because G_parser() will
complain about illegal characters and "string" won't work insofar as the
GUI won't provide a browser interface for it.
>
I generally agree, I perhaps mentioned this several times. For the future,
we need some higher level types. Some types are in "standard options" but
they are not exposed. Another example of higher level types would be
binary file and text file (as opposed to any file), GUI is now providing
direct/interactive input box for binary files. With "color rules file" we
can provide a GUI editor with preview besides the textual input.
However, for this case, I think that the following is better option.
> One solution would be to add a separate option (e.g. names=) which
accepts multiple valid map names, mark pattern= and names= as mutually
exclusive. names= would support multiple options and some form of
browsing, pattern= would be a plain string. Similarly for exclusion.
>
This is quite simple and it also solves the problem I was afraid of: users
seeing the option named pattern and not willing to use it because they
want to input a map name not some pattern they don't understand. Option
named `names` fits well with this use case. `maps` would be more
consistent but it would not be precise and `names` goes well with
`pattern`.
> Another solution would be rename g.remove to e.g. g.mremove, remove the
pretence about pattern=/exclude= being something other than "arbitrary
string", and add a g.remove script which would be a thin wrapper around
g.mremove (possibly the only difference would be to re-declare the types
of the pattern=/exclude= options).
This might go against the reasons for doing this whole thing, reducing the
complexity of interface and maintenance cost by reducing the number of
modules:
* http://osgeo-org.1560.x6.nabble.com/g-mlist-list-multiple-types-from-
all-mapsets-td5142385.html
Or were there some other reasons?
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2437#comment:14>
GRASS GIS <http://grass.osgeo.org>