[GRASS5] Problems with vector import, and a suggestion

[Glynn Clements]

Michel Wurtz wrote:

> I know, some people would like a m.in.e00.pg program, but i am a little
> reluctant to do that : there is far too many functions in grass.  I'm
> afraid that this will confuse beginners. Grass is too much stucked in
> the early implementation choice, mainly the display system : it's a
> hack on a hack on an old system designed before the standardisation of
> windows systems (X-windows + MSWindows + MacOS cover actually more
> than 99% of the GUI market).  So I am working on an graphic
> interface like ArcView or Mapinfo for Grass.  Curently, I have finished
> the specs but hesitate for the implementation between tk (nice,
> portable, but what about performances ?), kde or at least the Qt lib
> (portable on windows, but not enough gpl for many peoples) and Gnome
> (very gpl, but yet instable, and what about windows ?).  If there is
> a nice and user friendly user-interface, it is important to have it
> working on Windows.
> 
> I don't want a (once again) long thread about the comparative merits
> of Tcl/Tk, Gtk and Qt, but if some of you have some experience with
> more than one of those tools, I will be happy to have comments in my
> private mailbox.  I will summarise and reveal the choice I finaly made
> in this mailing list !

Some comments:

1. Have you considered using WxWindows? This provides a layer on top
of the platform's native toolkit(s). This may provide better
integration than a toolkit which is built from scratch on top of the
platform's lowest-level components.

2. Qt requires C++, which is a disadvantage from a portability
standpoint. Also, I still don't quite understand TrollTech's licensing
position.

3. The most recent version of XDRIVER can use a window supplied by the
application, rather than creating its own (via the XDRIVER_WINDOW
environment variable). This won't work for the libW11 port, but
Windows should really have a native driver anyway.

4. By GUI, I hope you're talking about a front-end (in the sense of
tcltkgrass), and not a monolithic program. I've previously outlined
the serious problems with the latter, but can clarify/elaborate if
necessary.

5. Right now, the most useful GUI tool would, IMHO, be something to
manage display "layers".

Each layer would effectively be a d.* command. Layers could be added,
removed, re-ordered, temporarily disabled and re-enabled, and changed. 
The program would automatically refresh the display when the state
changes. Other features could include:

+ Save/load the current state
+ Render to an image, via the PNG driver
+ Print, via ps.map (although that has some limitations)
+ Zoom/pan, i.e. change the current region

This could be either be a standalone program, or added to tcltkgrass.

6. I'm looking into replacing the display architecture eventually;
PostScript is the main contender, with SVG and OpenGL as alternative
options. This won't happen soon, but I'd welcome comments regarding
the design of any future display architecture.

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