[GRASS5] Platform for next generation UI

Russell Nelson nelson at crynwr.com
Tue Jan 3 00:43:34 EST 2006

Glynn Clements writes:
 > 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.

Why?  It works just fine with SMTP, NNTP, FTP and probably a few other
protocols.  But that's the point -- if it's really a protocol that can
also be used by a person, then that's what it is.  The complete
opposite would be running every command in a pseudo-teletype and
parsing its output as a screen reader would, then forcing keystrokes
at it.  The first is perfectly fine; the second is completely insane.

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

I think by interactive you mean the second of my two above, and by
"non-interactive" I think you mean the first.

But can I point to a different model?  It seems as if currently, GRASS
GUIS invoke command-line programs from inside themselves.  I think it
would be better to have the guts of each program actually reside in a
library, with the command-line interface consisting merely of
a non-interactive or interactive shell around the library call.

Most modern scripting languages allow easy access to libraries using a
binding module.

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

GRASS already depends on the shell; removing that dependency and
adding Python would not be a fatal dependency.  If the command-line
interface to the library function was written in Python, that would
reduce the amount of code that needed to be compiled for each
architecture.  It would also create example code for each library

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

Python is only slightly harder to write than pseudo-code.

..... not that I have any credibility in the GRASS community since
I've never been able to figure out how to use GRASS.

--my blog is at     blog.russnelson.com         | A computer without Python is
Crynwr sells support for free software  | PGPok | like a CPU without memory:
521 Pleasant Valley Rd. | +1 315-323-1241       | it runs, but you can't do
Potsdam, NY 13676-3213  |     Sheepdog          | anything useful with it.

More information about the grass-dev mailing list