[GRASS-dev] Modules

[Glynn Clements]

Brad Douglas wrote:

> > Counterintuitively, we can make GRASS much more interactive only by making
> > it possible to completely turn off any interaction built into the functional
> > modules that make up GRASS. For some modules, this is pretty easy. For
> > others, like v.digit and i.ortho.photo, it is more difficult.
> 
> I'm slowly getting through the imagery modules, but have not committed
> anything, in part because of BLAS/LAPACK.  IIRC, little things like
> i.ask can be removed simply by updating the code to use Option, etc.
> Most of the imagery modules have not been touched in many years.
> 
> Making the modules non-interactive is not terribly difficult.  In the
> case of i.ortho.photo, coordinates could be passed in either in vector
> or text format.  But I insist that an interactive point selection option
> be made available when coordinates are not known in advance (especially,
> in the case of i.ortho.photo where residuals are calculated).

The problem is that we have maybe a dozen modules all implementing
interactive editing of point data themselves. If you wanted to add a
particular feature to all of them (e.g. select all points within a
circle, or select the closest point to a user-specified x,y
coordinate), you have to implement it separately for all of them.

> > V.digit specifically is the second issue. For convenience and to ensure that
> > there is always a tool to create and edit GRASS files, a digitizing package
> > built into or accompanying GRASS is highly desirable. However, Glynn's point
> > questioning the current team's ability to create and support such a package
> > is well taken. If something like v.edit can be further developed, it may
> > make this possible. But we are not there yet and it will require
> > considerable work to make it function as we need it to. QGIS may offer
> > another alternative. It is farther along, but still has a way to go (at
> > least on my Mac). As I recently said to Glynn offlist, a third possibility
> > that might be almost as desirable would be if someone in the OSGEO world
> > decided to create a multi-platform, multi-format, dedicated digitizing
> > package that could create and edit various OS GIS files.
> 
> At least I understand the point of the discussion, now.  Option 3 would
> be ideal, but probably not very realistic.  I would only consider QGIS a
> serious option if the projects were merged, which is probably not
> likely, either.
> 
> I have no good solution (or bad solution, for that matter :-) other than
> settling on a single GUI that works well across platforms and
> deprecating others.  I imagine that wouldn't go over very well with
> users.

Don't consider the issue in isolation. So long as the raster graphics
architecture continues to serve as both a graphics library and a UI
library, the graphics side is going to remain incredibly primitive.

Also, anything using the modal R_get_location_* input model is
guaranteed to suck. GUI libraries have universally adopted an
event-driven input model because it produces better software (as you
don't have to explicitly handle all possible options in each
individual modal loop; or rather, cull the set of possible options to
the most critical ones).

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