#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev