[GRASSGUI] graphic overlays

[Glynn Clements]

Moritz Lennert wrote:

> > there are precedents. I agree that we always need to minimize dependencies
> > as much as possible. But some are unavoidable, or at least highly desirable.
> 
> I my understanding, the issue is not about dependencies, but about 
> trying to avoid diverging development of two versions of GRASS: CLI and 
> GUI. If we start adding more and more features to the GUI which are not 
> available on the CLI, people might be obliged to use the GUI to access a 
> specific feature, just because it was easier to code this for the GUI 
> than for the CLI, and so noone bothered for the latter.
> 
> In my eyes, the GUI should be a convenience, not an obligation.

FWIW, the above is essentially my position also.

> The examples you cited for justifying going directly through the GUI are 
> all doable in the modules directly. It is obvious that we are more 
> limited in developer power in C (although seeing the speed at which you 
> learned tcltk and python, I don't think it would take you very long to 
> get the gist of C ;-), but these are typically "small", well 
> circumscribed tasks which we can try to tackle through Google summers of 
> code, or even try to get institutions which use GRASS to contribute some 
> development financing for... It might not be as fast as doing it through 
> the GUI, but the final added value will be higher, IMHO.

Alternatives to C include using d.graph or creating Python bindings
for the raster/display libraries.

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