UI: Qs to get the ball rolling

[Francois-Rene Rideau]

Dear Joyous Tunespeople,

   In my previous message, I dared say:
>    It seems that the UI project goes from two directions:
> * defining small standard generic modules, which is building the HLL standard
>  library.
> * building interfaces between existing low-level objects and the previous,
>  that is, HLL specifications of these: accessing the video memory as an
>  array, but with special functions satisfying some relations, etc...
   Ark ! In my haste, I forgot the most important (that's not the first time -
see some previous message): !

   The first point was much related to the UI, but was a subproject of the HLL;
the second point was likely a subproject of the LLL.
   Those are part of the UI subproject, and the UI project will indeed have to
cooperate tightly with HLL and LLL; actually, all projects must cooperate
tightly. But that's not all of it: the UI project strives to define generic
and specific objects that help the human easily use, search, learn, maintain,
upgrade, or scale down the objects in the system.

   Here are examples, among others:
* a "preference" manager, so that human user can define contexts, specific
 or generic, founded or parametrized, simple or combined, in which he can
 view other objects. A straightforward application is to manage layout of
 windows in a GUI: it manages how where do display windows, what color/font
 to use, what editor, etc, etc; the user can have standard layouts, standard
 automatic laying out functions, many persistent current layouts, etc.
* structured object editors automatically computed from an object's structure,
 with human parametrization: arrays will be accessed as arrays on the screen
 (like Excel sheets), records as forms, reals as text, scrollbars, knobs,
 joystick position, etc; colors with text name, point&click interface, etc;
 the user (through the preference manager) will persistently modify those
 defaults, to achieve very efficient interaction; he can choose automated
 (pre-recorded or computed) inputs instead of interactive ones, combination
 of interactive and non-interactive ones, just anything.
* an abbreviation/completion manager, that would be again context-dependent
 and highly parametrizable: thus anywhere in the system, and with standard
 input tools (with history, menus, etc), the user needs not write everything
 when there's redundancy. Standard Unix shells do filename completions; tcsh
 and zsh have configurable completion, zsh has fully programmable completion.
 Emacs have some abbreviation manager too. All of these are difficult to use.
 I'm sure we can built some abbreviation manager that would be much more
 friendly, thanks to our orthogonal annotation mechanism.
* an "undo" manager, that records all changes, so every change is reversible,
 up to some point. This can be done in full cooperation with archiving
 mechanism that incrementally save meaningful modifications to floppy/tape.
 With active annotations, it can be done orthogonally to other kind of
 programming, and will be  far more reliable than existing incremental
 archiving programs, that have  coarse time grain, and save blindly
 unmeaningful things. By saving only the  right information (e.g. the
 compressed cooked keyboard/mouse input, etc), plus periodical (once a month)
 saving of original objects (e.g. no need to have a backup of the GCC
 distribution when you can get it by FTP, or the 10 Meg output of a lame
 FORTRAN program that's more easily recomputed than saved to floppy), we can
 provide an archiving both *far* more reliable and *far* more efficient than
 existing crap.
* A syntax for the HLL. This is really a UI problem ! Help !

   Well, perhaps the UI project should be renamed as just Interfaces, as
you see that its range is the interface between objects, the human input
being only particular objects.
   I can't forgive myself to have forgotten all that. I do it frequently,
but when I'm lucid enough, I *know* the UI project is a truely important one.
Please forgive me.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW URL: http://acacia.ens.fr:8080/home/rideau/Tunes/
IRC: on undernet (e.g. /server us.undernet.org) channel #Tunes
FTP SITE: ftp://frmap711.mathp7.jussieu.fr/pub/scratch/rideau/Tunes/
contains full (~300K) distribution, regular patches (~30K) to upgrade,
and the full (~1400K) mailing list archive for MOOSE & TUNES.
Get any by mail and/or subscribe to patches by sending me mail.