The Tunes Interfaces Subproject
Project scope
- Introduction
-
The Interfaces subproject is devoted towards
exploring how computers and humans will interact,
and specifying the standards that Tunes shall recommend.
This includes humans speaking to computers,
computers speaking to humans, computers speaking to each other,
and even humans speaking to humans, though we will restrict
ourselves to the strict necessary on that last, controversial, topic.
-
The device that ultimately (as far as computing is concerned)
interacts with the human is called a terminal;
the building of devices is an issue of hardware technology,
and escapes the scope of the project.
The nature of the computations that be run on a computer,
the algorithms and heuristics and their implementation,
also escapes the scope of the project:
they are a matter of programming theory and practice.
What is left?
Well, the tenuous strings that link these components
one to the other -- so vain yet so necessary;
so bulky, yet so poor.
- Terminal Independance
-
An essential feature that Tunes will provide is Terminal Independance:
the fact that programmers need not worry in any way
about how the information is communicated with the human:
be it text, 2d or 3d GUI, braille, voice, morse, telepathy,
or whatever technology will make possible.
-
In contrast, due to the blatant inexpressiveness of their interface algebra,
current systems enforce dependance on the worst possible terminal!
With Unix and mainframe systems, this worst possible terminal
has been a primitive "tty" (text grid and ASCII keyboard on a serial line),
to the detriment of users condemned to such stubborn technology;
since the advent of the Apple MacIntosh, the rule has become a WIMPish GUI
(Windows, Icons, Menus, Pulldown menus), which is better,
but an enormous waste of hardware and software resource,
and still a very limited way to communicate, that does not adapt
to computing by people not sitting in front of a desk
(blind people, people having physical activities, people moving, etc).
- Abstract Interfaces
-
As always, reflection is essential as to allow terminal independence:
it allows the abstract meaning of computations to be kept abstract,
and to consistently concretize it afterwards.
Concretizing an abstract meaning into input/output to a terminal
is exactly what an interface is all about.
-
The goal of the Interface subproject will thus be to build such interfaces.
However, objects are constructed in a rich algebra,
and constantly building new interfaces for every new constructed object
is a tedious task;
reflectivity is again the solution, as it allows the interfacing objects
to follow and wrap the structure of objects;
interfacing is thus made a particular case of representating,
and can use all the richness of the reflective algebra;
hence, instead of building terminal interfaces for every terminal object,
several interface constructors are built for every object constructor.
This allows for automatic, generic, modular, and incremental interfaces
instead of only manual, specific, bloated, and inextensible interfaces.
Abstract programs see implicitly interfaced objects,
achieving independence from the concrete interface.
Another side effect is that just any object can be dynamically interfaced,
instead of just a few objects statically choosen by the initial developer
(of course, objects that will have been given more care will look better).
-
Defining such abstract interfaces is to do in tight cooperation
with the HLL subproject, that defines the algebra in which
such abstract interfaces are built.
However, Interfaces subproject will not substitute to the HLL subproject:
it will use the algebra provided by the HLL subproject,
giving back useful feedback, suggestions and proposals,
from a priviledged position, but it will not design the algebra itself.
- Concrete Interfaces
-
Concurrently with the definition and specification of abstract interfaces,
the Interfaces subproject will develop concrete interfaces:
concrete ways for humans and abstract programs to interact.
This would begin with textual syntactical representations of abstract programs;
then, output on a two-dimensional display would be added,
be it with text grids or a graphic screen;
interactive timely input, "event programming"
(as opposed to raw sequences of data) will be added,
be it from keyboard, mouse, joystick, eyemove-tracker.
-
We would then have equalled the stupid GUI interfaces of today,
and could begin to explore forward, using reflection to seamlessly integrate
our improvements to existing and future software:
voice recognition and synthesis, input anticipation,
only our imagination will be the limit.
- Conclusion.
-
There sure are lots of user-interface experiments that have been led already,
by lots of specialists;
but the closed structure of both these experiments and system software,
their being both non-reflective and proprietary, prevented any achievement
from being made useful to the computing world at large.
-
The Tunes Interfaces project does not pretend to do better
than those specialists;
our goal is to begin a framework, to lead the way,
and show how a free, reflective, system, allows all the software improvements,
however small, to benefit the whole world, and to eventually do better
than the highest exploits of even the best teams of geniuses,
whenever those teams are isolated by the limiting technical and political
infrastructure of non-reflective and proprietary software.
-
That's why a free reflective system like Tunes
is a necessity to the improvement of computer software.
Our hope is that once our point becomes obvious,
technically and politically free software
will become the rule of
TUNES is a project for computing freedom.
Project Members
- Former Project Coordinator:
Chris
- I (Faré) have been progressively rewriting lots in the project.
Plan of Action
HLL
- design a straightforward language syntax
- We need construction, and annotation,
with a way to reflectively transform
between annotation into construction.
- LISP or ML look like a good start.
- See how Guile does multi-syntax support,
for more human-friendly syntaxes.
- See how POP, ILU, CORBA do it.
- Design interactive input methods
- Get inspiration from emacs for basic edition.
- See how Centaur does it, for structured object handling
(not all object are made of sequences of text lines).
- Remember that the input needn't be a straightforward representation
of the output -- completion is good;
move redundancy where it is needed.
- Make it easy to invoke or not invoke heuristics
for completion, translation, etc.
Fool and Leekh
- Find strengths/weaknesses of existing UIs, as well as new
technologies that may be coming down the road. Design and
impliment a new UI API for Tunes based on these findings.
- TUNES wants to be able to support all classes of computations.
Let's look at some of the availible classes, to see how they might
be implimented in a eutopian(-wannabe) OS.
- build, for text, graphical, audio, ... UIs
"some automatic (but programmable)
interface generators for structures (that is, if I define a
structure, automatically generate the behavior of the
structured editor for it). Let's take basic constructors
lists, vectors, meta-constructors"
Internal Developments
(most recent items first)
Automatic Interface Generation
On Word Processing in Tunes
On Games in Tunes
Tunes against the WWW
Worlds E-mail List Thread: lots of good, old discussion.
Basic ideas thereof:
- All TUNES interaction (both user and machine-based -- there's hardly
a difference) takes place in the context of a "world". You "log in"
to a world, as opposed to opening a shell, and interaction is based
therein.
- Sub-worlds/sub-objects provide for different "frames" of interaction --
a text world might replace your word processor, for example.
- Worlds can enhance/enrich the semantics and interface of an object,
but cannot be allowed to disrupt the basic semantics of the object.
- Worlds should not provide undue abstraction
- Every object exists in some world, weather it be a visible one, or in
some "hard world" -- like on disk
- Unresolved: can objects exist in more than one world at a time?
What's Wrong With Today's UIs and What We Can
Do to Help: old musings of Chris
Elsewhere on the WWW
WWW UI Links
Up to the Tunes home page
Page maintainer (no more):
Chris
(chrisha@simba.lakeside.sea.wa.us)