[GRASS5] Platform for next generation UI

[Glynn Clements]

Trevor Wiens wrote:

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

No, I'm saying that modules should, wherever possible, work with or
without a terminal. No writing prompts on stdout and expecting a reply
upon stdin; that won't work if the module is called from a GUI.

If a module is inherently interactive, there needs to be a
non-interactive alternative.

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

That situation is harder to solve.

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

Some of them can be done separately to consideration of a 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?

Personally, I would consider adding functionality to d.m to be
preferable.

I'm not specifically recommending wxPython (mainly because it adds
three new dependencies: Python, wxWindows and wxPython), just that
it's another option.

I'm also not suggesting building a complete prototype GUI. Rather,
that some modules need to be re-worked to make them more GUI-friendly
by removing interactive aspects. Doing so will leave certain
functionality missing from GRASS. A quick solution would allow the
changes to be made without leaving GRASS unusable for an extended
period.

Otherwise, GUI development could end up deadlocked, with the GUI
waiting on changes in libraries or modules, and those changes being
blocked because they would remove functionality which will be missing
until the GUI is ready.

> For a GUI, why would one need C++ or C for the majority of it

You don't absolutely need them, just that there are more C/C++
programmers out there than Python programmers, and more systems with
the relevant libraries already installed.

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

Using a minority language is likely to limit the number of people who
will work on the code. This is more of an issue for maintenance than
for the original development.

-- 
Glynn Clements <glynn at gclements.plus.com>