[GRASS5] g51 v.digit

[Christoph Hoegl]

> 
> Russell Nelson wrote:
> 
> >  > This problem already exists. The only real solution is an overall user
> >  > interface solution (tcltkgrass doesn't really cut it), which is
> >  > inherently a hard problem.
> > 
> > What about stealing bunches of code?  The gimp already displays
> > bitmaps, and has code to operate on bitmaps.  Seems to me that it
> > already does most of what is expected, with one obvious exception:
> > coordinate systems.  And the gimp already runs on Windows, so that
> > with ordinary care to preserve the existing portability, no
> > portability would be lost.
> 
> Well, the GTK+ FAQ says:
> 
> 	1.10. Is there a Windows version of GTK+?
> 	
> 	There is an on going port of GTK+ to the Windows platform which is
> 	making impressive progress.
> 	
> 	See http://www.iki.fi/tml/gimp/win32 for more information.
> 
> However, that link is broken.
> 

This link is obsolete as gtk+ (which also provides hooks for OpenGL/Mesa
DND and a lot of other fancy stuff) already supports win32 internal
The last changes regarding gtk+ && win32 were made 2002-10-07 on the
gtk+/gimp/gnome cvs

> Or we could just decide that you need an X server on any platform
> (this is already the case for NVIZ and tcltkgrass), in which case any
> Unix/X11 toolkit would suffice.
> 

In that case why not really drop tcltk and NVIZ Display routines altogether
and have a generic output API so everyone could choose the GUI he prefers
(I really like gtk+ as I was (small) part of it's evolution connected with 
"The Gimp" some time back and use it more or less once every week for tooling)

(I really like tcltk for most not computing intensive apps but GRASS becomes 
more and more intensive with regards to on screen display capabilities)

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)

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;-)

Anyone else willing to join that task force?

kind regards,
Christoph


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