[9fans] RFC: menu server for UI

[tlaronde@polynum.com]

Hello,

I'm the developer of KerGIS, a restart from the C.E.R.L.'s G.R.A.S.S. 
GIS software under a BSD like licence.

I have already cleaned and fixed the sources mainly for ISO C and POSIX
compliance (yes, I know...) and the whole thing is already used in
production but there is a lot of work still to be done, for example in
the user interface area.

Since the original code is rather "old" --- almost 20 years --- the way
the graphics were drawn was not linked to any widgets library. The GPL
GRASS team thinks this is a problem, I found this is a chance.

Since I have to remake or at least extend things, I had the opportunity
to think about the interaction between the user and the aim of the
program (that is not to provide an UI but to do some processing) and the
basic ideas were:

1) the processing program does need only to receive commands to tell it
what to do. Since all the programs are accessible from the command line,
there shall not be several distinct versions depending on the user
interface: the CLI program will be fed with command lines, coming from
a file (call it stdin or other) ;

2) the interaction with the user, until she decides to select something
(an action) is the problem of the interface ("the terminal") : poping,
changing, etc are an internal problem, only the result has to be known
by the processing program.
The problem with usual toolkits is that the menu handling is handled by
the client program, on the server, not by the terminal (leading to significant
network load).
Ideally I'd like an organization such that a process is tightly coupled
to its "data", that is the processing of a raster or vector file on a
CPU with a fast connection to a fileserver, and the menu handling tightly
coupled to the display (probably, since memory requirements are low, on
the terminal, leaving the network alone).

3) Raster processing is mainly an integer stuff. Vector is, at the
moment --- it could make sense in the future with increasing size
of machine word to have an integer vector format à la Intergraph
DGN --- mainly a float stuff.  Menu handling is mainly an integer
stuff (while graphics are more involved : vector graphics can be
all integer at the moment, but handling circles at least etc involves
transcendentals etc.).

At the moment, the graphics produced by KerGIS programs are handled by a
"server" listening to a named pipe and receiving graphical commands:
there is a X11 server, a MetaPost and PostScript drivers are planned etc.

Applications do not need to know what is the exact graphical server
serving their needs: they only generate commands.

This is thought as a weakness by the GRASS GPL team, while I think this
is simply great...

The "menu" interface is for now exclusively curses (text based).

After thinking about it, I see the things like this:

a) CLI is dimension 1 interface (the line). Hence it does indeed
make sense that, in this case, ed(1) is the preferred tool for
dealing with "dumb" terminal ;

b) Even curses is a dimension 2, a special case, where the element is
not a dot (pixel) but a group of dots (a glyph). Hence text can be
implemented in a dot based dim 2 (graphics), and even graphics, to some
extend, can be implemented in a glyph based dim 2 (text): ASCII art for
example.

So I envision to:

1) keep the graphics interface ;

2) in the same mood create a menu server reading from a file, a server
that could be, on an Unix a curses server, or a Xm server, or a KerGIS
menu drawing to some frame of the graphics, or a draw on Plan 9 etc.

Depending on the environment (the namespace), user will decide what type
of menu is preferred (or possible) --- I personnally like text based
menu: with two screens, one with text menus and the other with graphics.

With this organization, there is only one program (an editor) whose
interface is decided by the namespace. The processes are distributed, 
and CSP can be applied etc.

After reading a bunch of Plan 9 and related papers, it seems that this
is precisely one of the design aspects of Plan 9, or sam(1) etc., so I'm
not inventing anything but probably only misunderstanding some things.
Please tell ;)

And for the command language of the menu, since limbo uses tk, is it
simpler to use that? What do others think?

Last note: I will begin by developing graphics server for Plan 9 using
draw(3) and arrange so that the whole thing is runnable using APE.
But I think that KerGIS will, eventually, become a Plan 9 native thing 
(Plan 9 is simply what is needed for such an application) with
perhaps a POSIX compatibility. I'm not even sure that in the long term I
will maintain the latter...

Comments welcomed,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C