Christian Wygoda | 15 Apr 2002 06:40

GRASS GUI

Hi everyone,

Looks like the talk on the right GUI for GRASS is getting a little
warmer... While QGIS is a very good GIS application supporting GRASS I
think that what Michael, Martin and myself are exchanging thoughts about
now is where GRASS's *own* display abilities are headed.

As GRASS moves to version 7, it is only natural that the display module
of GRASS is part of that process. In my opinion the d.* modules and
especially the interface to them do not reflect current GUI abilities.

So let's keep pondering where me might head with that. If we in the end
start work on our own GUI for GRASS is not yet said though some might
think that this is neccessary (that includes me).

Crischan
Christian Wygoda | 15 Apr 2002 06:49

More GRASS GUI thoughts...

Hi everyone,

This discussion really make me itchy to help with the next generation
GUI for GRASS. Let`s talk on about the features we need. Adn please
don't mind if I tend to look for the Qt side of life. It's the toolkit I
have choosen a long time ago for my programming projects and has served
me well so far. I'll keep the Qt mockup up to date with this discussion,
time allowing. I can still use it as a good template for a complex GUI.

> Christian,
> 
> Thanks for your detailed comments. Sorry about taking awhile 
> to get back to you. For some reason, my spam filter ate your 
> email. I think I've got that fixed now--I hope.
> 
> There are a *lot* of good ideas here. I still think it's best 
> to separate for discussion a set of specs for a UI and the 
> toolkit/platform with which we implement it. This lets us 
> focus first on how the UI should function and look, without 
> sweating over platforms. In fact, once the UI specs are 
> worked out, a platform choice may be obvious.
> 
> Once we settle on a set of specs, however--and I'd like us to 
> be visionary as long as it's realistic--then it *would* be 
> nice to have a mock-up so that everyone could get some idea 
> of how GRASS could look to the user.
> 
> You make a good case for a separate render/display button. My 
> reason for not having it was 1) to keep the interface as 
> simple as possible (fewer buttons) and 2) to make it easier 
(Continue reading)


Gmane