[GRASS5] Platform for next generation UI

[Trevor Wiens]

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?

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)