User Interface
Mike Prince
mprince@crl.com
Thu, 22 Dec 1994 02:56:42 -0800 (PST)
On Wed, 21 Dec 1994, Chris Harris wrote:
> Well, if you have anything I should have running around in my brain right
> now, feel free to let me know. I should probably assemble my ideas for
> public comment in some document (a UI charter?), but I'm currently
> getting over the coolness of and getting the hang of my new P90 running
> Linux. =)
Congratulations on the Pentium.
Here are some rough ideas in no particular order;
The mainstream will tend towards a graphical windowing interface,
so its a good start.
One named cell is in charge of each terminal. Actually there will be a
collection of cells (family) running it but all that matters
to us is the name of the cell we need to call.
Each terminal will be capable of displaying bitmaps (at least 2 colors,
up to 16M). If we provide a bitmap, we should give reference colors.
It does not actually matter whether these map onto one video display,
or 10, or the size of them. (start flaming)
Bitmaps are directed to logical windows through handles. You send an
agent to the cell managing a terminal, requesting a window with
certain characteristics, and if you're lucky you'll get a handle
back (actually parms needed to communicate with that cell).
You also provide a cell name for interactive information from the terminal
to be sent to (keyboard hits, mouse clicks).
Typically a user (read human) would have a personal server that revectors
these cells. So if;
E1-En compute engines
R revector
T1,T2 terminals
You jump on T1. Start up a session which contacts your personal
revector R. You begin some computations which farm out onto E1-5.
T1 goes down half way through, so you jump on T2, which during
login contacts revector R which is queuing the results back from
the E's. If your revector has gone down as well, then if we're
lucky the OS still has the agents being sent to R in its message
queue. Reinstantiate your revector with T2, and we might be
able to start up again.
Mind you, this is not very well thought out yet. The important
concept is the ability to revector execution to different
terminals.
The screen has icons. Icons represent cells. You send an agent with a
request for an icon, and it comes back with a bitmap.
Icons really represent vectors to cells, actually just their name.
When you right click an icon, you send off an agent asking for
information about it.
When you left click an icon, you put that icons vector onto a terminal stack,
kind of like a graphical command line.
When you double click and icon, you send off your terminal stack to it,
through an agent.
So to print a document (which would be encapsulated as a cell), you left
click it to grab its name, and then double click
the printer icon. The printer cell could then start a dialog
with the document to accomplish the print. You could
also single click a bunch of documents, and with one
double click to the print cell, print them all.
Agents could have one of their data blocks allocated for saving a vector
to notify you of any problems. So if a print fails, the offending
cell simply looks up who to notify, and the agent is returned that
way (through the revector of course).
Back to windows...
The terminal is in charge of screen rewrites, moving windows around,
minimizing and maximizing.
I'd like for the terminal to be programmable at the window level. You send
descriptions of touch sensative areas of a window, and cell names
for handlers. When a mouse click happens in a sensitive area, that
handler is called (probably from a library local to the terminal).
We might even be able to accomplish a hypertext like capability,
although far more versatile. I.e. a click call's a cell in Australia
to get someones home page, or register a vote, or add your name
to a mailing list.
It's getting kind of late 2:50am so I think I'd better stop. These ideas
ARE half-baked. But it's fun to think about. Chris I wish you the best
of luck in working with the UI. I'm looking forward to talking more
about it, though at times I'll restrain myself to the LLL leagues.
Give Windows96 (or 97 now?) a run for its money!
Mike