[GRASS5] Platform for next generation UI

[Glynn Clements]

Russell Nelson wrote:

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

Engaging in an interactive dialog with a program is significantly more
involved than simply running it with specific arguments.

Networking protocols don't have command-line arguments, the examples
which you cited involve significantly more data than is communicated
to a GRASS module, the protocols were explicitly designed to be
machine-readable (e.g. three-digit result codes rather than
(localised) text messages), and are all client-driven (the client
sends a request, the server replies; the server doesn't ask the client
a question and wait for its response).

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

By non-interactive, I mean that all operating parameters are passed as
command-line arguments.

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

Re-working the guts of each module for use in a library which is to be
used by a long-lived application would be a lot of work, for several
reasons:

1. You need much greater robustness. A segfault in a module results in
the module crashing (i.e. the specific "command" failing); a segfault
in a library function will take down the entire application.

2. You need to make more effort to prevent memory leaks. Memory leaks
in modules don't matter unless they occur inside of loop with a high
iteration count. Memory which is allocated once per invocation can be
ignored; it will all get released when the module terminates.

3. You need to be able to re-initialise the state at each invocation. 
Currently, the core GRASS libraries use a lot of static data. This
data is initialised automatically at startup, and is discarded at
termination. For a library, you would have to be able to explicitly
re-initialise all of that data before invoking each command.

In short, GRASS relies heavily upon the semantics of program
execution, and removing that reliance would involve a thorough
re-write.

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