[GRASS5] Platform for next generation UI

Trevor Wiens twiens at interbaun.com
Sun Jan 1 23:51:28 EST 2006

On Sun, 1 Jan 2006 20:10:30 +0000
Glynn Clements <glynn at gclements.plus.com> wrote:

> Michael Barton wrote:
> > My main goal has been to try to have some kind of organized, coordinated
> > effort in developing a new UI. GRASS seems a rather diffuse open source
> > project, which means that it is open to a wider variety of contributors and
> > more difficult to organize. It seems like we need to get a few energetic
> > people to give a UI a trial run and then try to build some support for it.
> > I'm trying to spark that.
> One final point to bear in mind is that much (maybe even most) of the
> work required for a good GUI consists of making the rest of GRASS more
> GUI-friendly, e.g.:
> + Removing assumptions about having access to a terminal, or even to
> stdin/stdout.

I assumed that a new GUI would provide easier access for many functions
for new users, but that the CLI would still be central. Are you
suggesting that if we can't assume access to a terminal that bash will
need to be replaced with some GUI integrated CLI?

> + Minimising dependence upon global state (WIND, $GISRC, monitor pads,
> etc).

I would expect this would be highly desirable to addressing issues of
having multiple users accessing a single location at one time.

> + Improving modules' metadata (e.g. the information used by
> G_parser()).
> Part of that involves getting rid of stuff which is GUI-unfriendly,
> e.g. use of the vask library, G_ask(), R_get_location_with_*() etc. In
> order to do that without leaving GRASS in a crippled state, some of it
> will need to be replaced. In that regard, a basic GUI in e.g. Tcl/Tk
> or wxPython could accelerate some of the tasks which need to be done
> in preparation for a "real" GUI.

A number of ideas come to mind from this comment. Are you
suggesting that we should solicit volunteer help to help rework these
issues first before trying to develop a new GUI? If so, would it be
wise to then adjust the current Tcl/tk interface to match those
changes or are you suggesting using wxPython (I assume because it is
relatively easy to use) to build a concept GUI to explore usability
issues and then toss it? For a GUI, why would one need C++ or C for the
majority of it. Python allows calls to C or C++ libraries. Couldn't
rendering and other bits be built and called from a Python based GUI?
It strikes me as wasted work to start with something like wxPython and
then toss it. When I was working on my update of Stereo I was building
speed dependent bits in C/C++ and the front end in PyQt. I don't see
why this strategy couldn't be applied to GRASS using wxPython or PyQt
or updated tcl/tk.

I think that there is a tendency among programmers in general to apply
the tools they are most comfortable with beyond their optimal use.
Interpreted languages like Python are often quite suitable for GUI
development. So, I wonder if we should consider, using a hybrid
strategy especially if it will enable us to make the transition from
GRASS in its current state to a more GUI friendly GRASS. Further, it
that were to work, why rework the transitional GUI in C?

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