[GRASS-dev] GUI platforms

Trevor Wiens twiens at interbaun.com
Mon May 22 23:45:08 EDT 2006


On Mon, 22 May 2006 14:32:08 -0700
Michael Barton <michael.barton at asu.edu> wrote:

> 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

Do you envision something that would be a plugin replacement for
g.parser that would possibly allow for more interactive dialogues, but
would allow existing modules to work without modification. If so I
think this would be ideal, but not being familiar with that code I
don't know what is possible.

> 2. Provide a CLI interface for GRASS program modules

Do we need to drop bash? If so a lot of existing modules and add on's
will go away or need to be ported for 6.3. Or do we envision providing
something like a language based shell (eg Python) as well as bash for
6.3 to allow for transition and dropping shell programming for 6.4 or
6.5 (I now way out in the future, but worth thinking about so we don't
make short term decisions that limit that vision).

> 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.

For example something that will parse text and convert it to a gui
format?

> 5. Provide an interface for interactive attribute management for vector
> data. This is not currently handled in the GUI, but could be.

Yes, this would be highly desirable.

> 
> 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?

I think the opposite is a better way to think about this, can we in
fact lighten the load. The fewer dependencies possible without giving up
functionality is highly desirable from a maintenance and distribution
point of view.

> 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?

8. Does the platform under consideration create another potential
rewrite down the road. Right now we are talking about a complete
rewrite, because of the limitations of Tcl/Tk. I don't think we want to
find ourselves in this situation again any time soon, so if we come
down to two or three options and find that one will work for now, but
may limit us in the future, we probably want to remove it from
consideration.

> 
> 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.

I like the idea of taking some time to think about this as I am finding
I am continuing to learn about different options as this discussion
unfolds.

> 
> 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.
> 
>

Thanks Michael. 

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)




More information about the grass-dev mailing list