[GRASS5] g51 v.digit

[Glynn Clements]

Christoph Hoegl wrote:

> I really would like to join a task force for the implementation of 
> a) a Generic Display API (GAPI)
> b) the gtk+ Display System (GDS)
> 	e.g. it may be possible to revamp some NVIZ togl code for 
> 	GDS
> 
> What I personally don't want to see is some kind of monster application
> that needs 5 minutes to start just to change location
> so we should keep the console based variants as well (grass scripting 
> is really fun and beats most of the commercial click-ware interfaces
> both in routine (production) and experimental work)
> 
> It should be more like the tcltkgrass toolbar with plugins/modules
> for each grass command
> 
> like d.rast,v,rast,d.dm,nviz,d.* etc  -> main display routine
> with helper plugins/modules for typical console work
> 
> (just to keep the single system feeling)

Output-only programs (i.e. most of the d.*) commands aren't really a
problem; they will fit into any architecture.

The complicated bit is handling user-interaction, e.g. v.digit,
d.measure, d.what.* etc (to me, d.display has already been dealt with
by the introduction of d.dm).

The current tools are based around modal input, which is basically
dead as a UI concept, and with good reason. While this may be easy to
modularise, the end result sucks from a usability perspective.

A monolithic application would be much more usable, but also more
limited (and potentially much more fragile). So, we're basically
looking for a UI with plug-ins. However, that's easier said than done;
designing a decent interface for interactive modules is *much* harder
than for "fire-and-forget" commands.

> This approach would also allow for gradual implementation
> (perhaps 1 module/per week without the major display routine
> that covers the d.* commands that would take about 1-2 month of development)
> 
> I better stop now or I might just code the following night away;-)

The last thing that anyone should be doing in that area is coding. 
That's how we got into this mess in the first place; too much of
GRASS' code was written without any consideration as to how it fits
into the whole.

> Anyone else willing to join that task force?

A large part of the problem is that this isn't just a matter of
getting enough manpower. The problem is that the result needs to be
suitable for the purposes to which it will be put, and that requires
input from the people who are likely to make use of it.

And that takes time; the design will likely need to go through many
iterations of putting ideas on the table, getting feedback and
refining the ideas.

In the meantime, we are likely to be stuck with a situation where
highly interactive tasks (e.g. digitising) require dedicated
applications. Given that,, I'm asking that people (in this instance,
Radim) choose a better UI framework than R_get_location_with_*().

-- 
Glynn Clements <glynn.clements at virgin.net>