[GRASS-dev] GUI platforms

[Michael Barton]

The recent discussion over where to head in terms of GUI platforms for GRASS
is very useful. Here are some suggestions about how to proceed and structure
this important design decision. Please feel free to suggest or amend.

Primary functions of the GRASS GUI:

1. Provide a GUI interface for GRASS program modules. This includes simple
dialogs and more complex modules like v.digit that also require
visualization
2. Provide a CLI interface for GRASS program modules
3. Manage graphical display/visualization for GRASS geospatial
data--particularly raster and vector files, but also including display
enhancements like profiles, scales, text, grids, etc. This also includes
2.5-3D display handled by NVIZ and output of graphical displays to files for
inclusion in other applications.
4. Manage non-graphic output from GRASS commands--normally as text.
5. Provide an interface for interactive attribute management for vector
data. This is not currently handled in the GUI, but could be.

Some questions to ask about GUI platforms (not necessarily in order of
priority):

1. Is it open source and compatible with GRASS's GPL license?
2. How well can it accomplish the GUI functions? Most especially important
is how it can handle the display/visualization management since GRASS's
modular structure makes creating an interface to most commands relatively
straightforward (digitizing and georeferencing being notable exceptions).
3. How well can it create a consistent and platform-appropriate interface
across the many OS platforms on which GRASS runs? Ideally, we should only
have to code the GUI once in order to deploy it across multiple platforms.
In order for GRASS to be used easily on these platforms, how well can it do
this without relying on X11?
4. How easily can it be used by GRASS's volunteer developer community, most
of whom are researchers? This is important for both development and longer
term maintenance.
5. Does it require any special tools for development that might be of
limited availability? Are open source development tools available for all
platforms on which it runs?
6. Does it require any special packages to run that would significantly add
to GRASS's overhead or make installation more difficult?
7. How well and easily can it create a GUI that is easy to use--for both
newcomers and experienced GRASS users--and visually appealing?

Suggestions for the next steps:

1. Given comments over the past few months, it seems that developers and
users are generally satisfied with the design direction GRASS has taken.
Unless there strong arguments to the contrary, I suggest that we 'freeze'
this for GRASS 6.2 and simply work on bugs (tweaks, error trapping, fixing
region issues, finding and fixing other errors). I can try working on an
ipoints replacement if the general freeze for 6.2 drags on for awhile, but
am hesitant to put an inordinate amount of work into it if we are going to
change to a new platform soon. There are some other design issues that are
very much worth considering (e.g., replacing some or most of the menu
hierarchy with a toolbox approach, offering multiple display modes,
integrating 2D and 3D visualization in some way, creating an interface for
vector attribute management), but which can be left to 6.3.

2. Continue discussions as needed on GUI platforms. Once the 6.2 freeze is
in, take a vote on which platform to use. It would really help if people who
have some familiarity with whichever platform we choose are willing to help
start porting the GUI to that platform.

3. Start GUI development for 6.3 in the new platform. Revisit existing
design issues so that they can be addressed in the new platform.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton