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

[Glynn Clements]

Michael Barton wrote:

> >> It might well be possible to parse the existing interface description
> >> better. Perhaps Daniel will be able to look at it more. But, it's hard to
> >> imagine how to create a set of check boxes in such a way to generate a
> >> variable set of type pairs (line,boundary, point,centroid).
> > 
> > You can't do it with check boxes alone.
> > 
> > A common interface for editing lists is with two list boxes, one
> > containing the available options, and one containing the edited list.
> > In addition, there are buttons to add an option to the list, remove an
> > option, and to move options up or down. Some of this functionality may
> > also be available by dragging items within and between the list boxes.
> > 
> > If you have the restriction that an option can only appear once,
> > adding it to the list removes it from the set of available options,
> > and removing it from the list returns it to the set of available
> > options.
> > 
> > An example can be found in the Windows XP explorer (file manager), via
> > the "View -> Toolbars -> Customize..." menu option.
> 
> I've only done a limited amount of work on the autogenerated properties
> dialogs. Daniel has done much more on wxgrass and Cedrick did most of the
> updates to the TclTk one. So with that disclaimer...
> 
> This is certainly a nice interface (JMP stats uses it too). The issue is
> that the autogenerated dialogs depend on the xml interface hints to create
> their GUI. There would need to be some kind consistent hint in the module
> code to prompt either gui to build and populate the correct kind of widgets
> appropriately.
> 
> From my look at the xml generated by v.type, it doesn't seem to do a very
> good job at this currently, resulting in a minimally functional
> autogenerated dialog. Maybe there are hints there that I'm not
> understanding. But it looks like we could do with better interface hints
> with this module (at least having values as acceptable type pairs rather
> than as single types would make it easier) and then finding a way to
> transform them into a better interface.
> 
> That said, are there other modules that could benefit from the same kind of
> interface, or is this the only one? I can't think of any, but it's still
> early and there are 300+ modules.

In the absence of additional information, you need to use the above
interface for any option with ->multiple==YES and ->options!=NULL. 
I.e. everywhere that multiple checkboxes are currently being used.

--interface-description etc can only output the information which they
have available, i.e. the fields in the Flag and Option structures.

At present, there is no way for a module to indicate that it doesn't
care about the order. All of the autogenerated GUIs (including the
basic --ui implementation in lib/gis/gui.tcl) simply assume this to be
true, which falls down with v.type (and quite possibly other modules).

Similarly, there is no way to indicate that certain combinations are
valid. AFAICT, the only realistic solution is to make each valid
combination a distinct option, e.g.:

	type_opt->options = "point/centroid,centroid/point,line/boundary,boundary/line,...";

BTW, with the existing mechanism, v.type should probably have:

	type_opt->key_desc="from,to";

to indicate that the options have to come in pairs.

Ultimately, there are two issues here.

1. The GUI doesn't allow the user to specify the order of options.
This is a bug.

2. The Option structure doesn't have any way to indicate whether the
order is important, or whether options can appear multiple times. This
is a wish.

Even if #2 is dealt with, #1 still has to be dealt with for the case
where the module indicates that the order really is important. Once #1
is dealt with, #2 is just an issue of providing more specific
interfaces. A list interface can be used for both lists and sets, but
a set interface won't work for lists.

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