Hi,
I would like to change the interface of g.mapsets in G7. Currently
there are separate parameters to add, remove and set mapsets from
search path. My suggestions is to have only two parameters:
mapsets - List of mapsets to add/remove/set
option - add/remove/set
What do you think about that? Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Sun, Oct 24, 2010 at 10:03 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
I would like to change the interface of g.mapsets in G7. Currently
there are separate parameters to add, remove and set mapsets from
search path. My suggestions is to have only two parameters:mapsets - List of mapsets to add/remove/set
option - add/remove/set
It is debatable if that's better or more complex - in any case then the same
concept should be adopted also for other modules where stuff is added or
removed (categories, columns etc) - for CLI consistency
Markus
Martin Landa wrote:
I would like to change the interface of g.mapsets in G7. Currently
there are separate parameters to add, remove and set mapsets from
search path. My suggestions is to have only two parameters:mapsets - List of mapsets to add/remove/set
option - add/remove/setWhat do you think about that? Martin
One issue is that it creates a dependency between options, i.e. the
set of permitted values for one option vary depending upon the value
chosen for another option. None of those options currently provide a
list of valid answers, although that could change,and merging the
options would prevent it.
I would rather that we got around to implementing option groups. I.e.
rather than individual options having a boolean "required" flag, the
module enumerates the valid permutations. The GUI would then provide a
set of radio buttons, and the required/optional/unused status of each
option would change accordingly.
This would also solve the problem where a bunch of options which would
normally be "required" are all optional because of the presence of
special cases (e.g. a "list" flag) which override the normal
requirements.
--
Glynn Clements <glynn@gclements.plus.com>