[GRASSGUI] Re: managing layer and properties

[Glynn Clements]

Daniel Calvelo wrote:

> > In terms of the most effective use of our time, I'd propose the following.
> > Why don't we start with using the existing autogenerated gui panels--and
> > upgrading menuform to make it nice (use select.Select for maps and other gis
> > elements, add notebook tabs and icons like in the TclTk GUI, etc). The
> > latter needs doing anyway. Taking this route first, I think that we could be
> > up and running very quickly with a full-featured wxGRASS in short order. The
> > sooner we have something that is 80%+ useable, the sooner we can have
> > widespread testing, and maybe get some additional help in writing the
> > separate modules for georeferencing, profiling, and the like.
> 
> I've started looking into this. So far, it does seem easy to get a
> gis.m-like interface. As Glynn pointed out, it remains to be seen
> whether the current expressive power of --interface-description is
> enough for correct user experience.

We can guarantee that it isn't enough for "ideal" user performance;
there currently isn't any way for the module to provide enough
information for that.

One problem is that the data types are far too limited; there are too
many cases where an option's type is just "string", with no further
qualification, because none of the other alternatives allow for all of
the acceptable values.

Another problem is that there is no way to indicate relationships
between options. Either an option is required or it isn't; there is no
way to indicate that you have to specify one option or another. In
this case, you just have to mark all options as "not required" then
have the code perform the checks. Similarly, you can't specify that
certain options are mutually exclusive, or that certain options have
to be used together.

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