UI: Qs to get the ball rolling
Sun, 12 Mar 95 12:26:54 MET
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
> * 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
* 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 -- email@example.com -- 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.