[GRASS-dev] can wxPython GUI handle order of options for v.type and alike?

[Glynn Clements]

Michael Barton wrote:

> > I was wondering if the wxPython GUI is going to deal with problems the
> > tcl/tk GUI can't - when there is a set of pre-defined parameters to
> > choose from and the user should be able to decide about the order of them.
> > 
> > An example is v.type [1], for which in the tcl/tk GUI you can specify
> > the order of types only one way, eg. 'type=point,centroid', but
> > 'type=centroid,point' is impossible to achieve.
> > 
> > [1]http://intevation.de/rt/webrt?serial_num=2969
> 
> I agree that this is an annoying problem that makes v.type almost unusable
> from the autogenerated GUI. wxPython as a platform won't inherently be able
> to improve this, because the autogenerated dialogs can only display what is
> included in the parser strings of the C-command. BUT... this is a very good
> time to think of a better way to get this formatted in the C module so that
> the dialogs generated in wxPython (and even TclTk) can be useable.

The problem isn't with the information in the module, but with the
fact that the GUI mistakenly assumes that the order is irrelevant for
options with "opt->multiple == YES && opt->options != NULL".

[A related issue is that it assumes that each option will occur at
most once, when this doesn't have to be the case.]

IOW, the GUI assumes that the value is a set when it's really a list.

Now, it would be useful for the module to be able to assert that the
value really is a set rather than a list, so that the GUI can offer
more specific interfaces, but there's no reason why the GUI cannot
just assume lists rather than sets.

-- 
Glynn Clements <glynn at gclements.plus.com>