coord.html000644 057164 000036 00000005140 05712635513 014015 0ustar00chharrisuser000001 2207250 UI Coordinator Thread

UI Coordinator Thread

The Tunes User Interface Mail Archive

(Last modified Saturday, January 28, 1995 @ 1:30PM PST)
Date: Wed, 21 Dec 1994 11:09:58 -0800 (PST)
From: Chris Harris 
Subject: MISC: Multi-level thinking/development
Speaking of fun, do we have a UI project coordinator? If not, I'd be happy to volunteer. =)

More seriously though, I'd like to suggest that we need some kind of multi-level thinking going on here. Its great that everyone is thinking about the LLL, but people should be thinking about the HLL, distribution, persistant data, and everything else at the same time. (If we want to get into money-making business things, as Mike suggested, then perhaps we ought to have someone to evaluate how well TUNES fits into the business model.) Its not possible for each person to do all these things, but that's why we have so many people. If we don't take a more global approach to the problem, the higher-level stuff could be severely limited by the lower-level decisions, and vice versa. (Of course, this also doesn't exclude various mid-level pieces screwing themselves either.)

So maybe becoming UI coordinator isn't so silly right now. After all, how long do we want to wait for a decent interface? All of our end-user goals won't work without one.

Anyone else have these feelings?

-Chris


Date: Wed, 21 Dec 1994 14:20:07 -0800 (PST)
From: Mike Prince 
Subject: Re: MISC: Multi-level thinking/development
On Wed, 21 Dec 1994, Chris Harris wrote:
Speaking of fun, do we have a UI project coordinator? If not, I'd be happy to volunteer. =)
I'd be happy for you to help with that. Formerly (according to our charter) I was in charge of it. But I would be more than happy to hand it on to you. The UI is going to be a fun piece of software to work on and I have lots of ideas of how to do it.


Date: Thu, 22 Dec 1994 10:40:53 SAT
From: "Dr. J. Van Sckalkwyk
Subject: Re: MISC: Multi-level thinking/development
Chris-

I second your proposal of yourself as UI co-ordinator! Good idea.

JVS.


Click here to return to the Tunes UI mail archive.

Click here to return to the Tunes UI subproject.


Page maintainer:
Chris -- chharris@u.washington.edu
goals.html000644 057164 000036 00000026062 05712634265 014027 0ustar00chharrisuser000001 2205560 UI Goals Thread

Chris' UI Goals Thread

The Tunes User Interface Mail Archive

(Last modified Saturday, January 28, 1995 @ 4:40PM PST)
Date: Tue, 27 Dec 1994 23:14:44 -0800 (PST)
From: Chris Harris 
Here's some half-baked thoughts on the UI stuff. If anyone wants to rip it to shreads, feel free. As for me, I think its time for bed. =)

-Chris

UI Project

Coordinator: Chris Harris

Members: None

Purpose: To create a (set of) user interface(s) for the TUNES project. Note that UI includes every aspect of user interaction, and not just some pretty little pictures.

Goals/Proposal

We don't know where UI technology will be going in the next few years, so its best to keep an open mind/API where the interface is concerned. Therefore, I propose a modular UI system. When a user logs in, he(r) is presented with a primary UI of their choice. Their interaction is then funneled through this UI from the programs they wish to run to the native hardware.

Eventually, though, its likely that the user will run into a program which does not support his/her primary UI. If this is the case, a secondary UI will be loaded, and allocated display space within the primary UI. Totally incompatible programs cannot be run, and will result in an error.

Such a system could certainly be expandable enough to enclose any sort of UI we might need, and with enough standards, there might not be too much incompatibility. If things are thought-through enough, it might be possible to have the same APIs for a 2D or 3D program, and let the user switch between the two at runtime.

With that said, there are some goals that each UI module should try to accomplish:

  1. Easy to use - Attractive-looking systems are great, but if there isn't a productive way to get something done, people won't like it. Each availible UI should have some sort of purpose and/or specialty.
  2. Attractive/Fun to use - A UI should obviously have some human appeal to it, weather its because its powerful, elegant, or whatever.
  3. Minimal abstraction - The OS will be designed well enough (Right guys?) that that the higher-level internals of the system will be logical enough for the user to understand. Why now present it to him/her like it is, then? (Note: this is a general rule; certain UIs may better accomplish a certain problem via abstraction.)
  4. Easy to learn - This one's a big tricky, since it can violate goal #1 in some cases. If we don't go out of our way to make it difficult, we'll probably be fine. =)


Date: Wed, 28 Dec 1994 15:24:04 -0800 (PST)
From: Mike Prince 
On Tue, 27 Dec 1994, Chris Harris wrote:

Goals/Proposal

[snip]

I fully agree with modularity and expandability.

I like your analogy to a funnel. Raul (I think) and I discussed several months ago a data encapsulation scheme. I was imagining a UI whereas all requests would go into your UI funnel in the form of encapsulated data. Your UI (actually a mini-interpreter) would decompose this "message", executing what it could, and passing off sub-components to other modules.

If our OS has the capability to send messages to cells just by name then to increase the capability of you UI, you'd create a cell with the requisite functionality, and include a reference to it in your message to the UI (the encapsulated data). Forth like example:

HelloWorld:	// cell name
	"Hello World!" PrintString return

Main:		// another cell name
	[ "Explicit print" PrintString "HelloWorld" CALL ] UI
	end
This is actually pretty close to the way I envision the LLL looking. The first HelloWorld creates a cell by the name "HelloWorld" which is put into the domain directory. The cell pushes the string "HelloWorld!" onto the stack and calls the cell PrintString. An underlying detail is that each agent holds a variable naming it's output device, so PrintString knows where to print (which window for example).

Main is the program we want to run. Again "Main" is created and put into the domain directory. Main creates a block, the data enclosed in square brackets, which is passed on the stack to the cell UI (our user interface).

The UI breaks the message down, first pushing the string and then printing it. Then it reads in the string containing the name of our "extension". CALL then calls our routine, printing "Hello World!" to the device indicated by the agent.

This is a rough example, but it gets the idea across.

With that said, there are some goals that each UI module should try to accomplish:
I'm fine with your goals. I'll try to get you some documentation for what I'm working on so we stay in sync as much as possible. I'm appreciative for you taking this idea and running with it. Hopefully we'll have some code running together soon!

Mike


Date: Wed, 28 Dec 1994 16:37:58 -0800 (PST)
From: Chris Harris 
On Wed, 28 Dec 1994, Mike Prince wrote:
On Tue, 27 Dec 1994, Chris Harris wrote:

Goals/Proposal

[snip]

I fully agree with modularity and expandability.

I like your analogy to a funnel. Raul (I think) and I discussed several months ago a data encapsulation scheme. I was imagining a UI whereas all requests would go into your UI funnel in the form of encapsulated data. Your UI (actually a mini-interpreter) would decompose this "message", executing what it could, and passing off sub-components to other modules.

check.
If our OS has the capability to send messages to cells just by name then to increase the capability of you UI, you'd create a cell with the requisite functionality, and include a reference to it in your message to the UI (the encapsulated data). Forth like example:
HelloWorld:	// cell name
	"Hello World!" PrintString return

Main:		// another cell name
	[ "Explicit print" PrintString "HelloWorld" CALL ] UI
	end
This is actually pretty close to the way I envision the LLL looking. The first HelloWorld creates a cell by the name "HelloWorld" which is put into the domain directory. The cell pushes the string "HelloWorld!" onto the stack and calls the cell PrintString. An underlying detail is that each agent holds a variable naming it's output device, so PrintString knows where to print (which window for example).
Afraid I disagree with you here. First, I don't think people want to interact with cells. I see higher-level objects etc. as a better base for UI. There has to be something at the low level, though, so this might be it. (I'm working on some HLL thoughts, so I'll pass those on perhaps tonight.)

Most of my UI thoughts have been on a fairly conventional 2d surface, so let me talk about it in that light. I think if the user wanted to print HelloWorld, they would create a new text field or reference one that already exists, and then send it a print message containing "HelloWorld". (Actually, I'd probably send the text a message to print itself on the text field, but that's a minor point.) This same agent could also reference any text field (within reason), and would not be limited to only one.

I'm fine with your goals. I'll try to get you some documentation for what I'm working on so we stay in sync as much as possible. I'm appreciative for you taking this idea and running with it. Hopefully we'll have some code running together soon!
Well, at least we can agree there. I'm afraid this is turning into another high-level vs. low-level war, which is not good, to say the least. I think the user interface, though, ultimately needs to be a higher-level concept, as the users ultimately won't care about the LLL and its details.

I got a book on PC graphics programming the other day, and it looks pretty good. I'd like to start experimenting a bit with some stuff here, but I don't know how to get Linux to allow me to access the hardware directly, and I don't have a DOS compiler. My hunch is that info is stashed on this neat CD-ROM I have, but I can't find a cable that'll go from my super-new SCSI port to a plain 50-pin. =) If anyone has any hints on this, please let me know. If I'm going to be playing a lot with graphics, I'd like to know something about it. =)

-Chris


Date: Thu, 29 Dec 1994 01:02:49 -0800 (PST)
From: Mike Prince 
On Wed, 28 Dec 1994, Chris Harris wrote:
Afraid I disagree with you here. First, I don't think people want to interact with cells. I see higher-level objects etc. as a better base for UI. There has to be something at the low level, though, so this might be it. (I'm working on some HLL thoughts, so I'll pass those on perhaps tonight.)
Sorry, I'm stuck in the LLL programming mode. Of course most programming would be done in the HLL. I'm only showing how little LLL code it might take to accomplish tasks, and how the OS parts might interact.

I'm afraid this is turning into another high-level vs. low-level war, which is not good, to say the least.
Don't worry, I think we were just looking at the same thing from two different views. The UI has to be a high level concept as you said.

Mike


Date: Sat, 31 Dec 94 02:33:08 EDT
From: jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.)
Just a few quick comments: Chirs was wondering on December 29 about how to access video hardware directly in Linux. My Slackware 1.0 distribution came with svgalib. If you don't have it, I am sure it must be easy to find. Try:
find / -name "*vga*" -print
just to see what you have. I haven't done much with it yet, but it doesn't look too hard.

I found the book:

   "Computer Graphics Using Object-Oriented Programming"
   Edited by Steve Cunningham, Nancy Knolle Craighill,
   Martin W. Fong and Judith R. Brown
   Wiley Professional Computing - John Wiley & Sons, Inc.
   ISBN 0-471-54199-0
very educating. I must admit that I learned more about how not to do things, but it was very interesting and recomended even so.

My Merlin UI is only three-D in the sense that the objects float around in space. The objects themselves are no more 3D than on the NeXT or in Windows. I hope to change this in the future, however. For a look at the true potential of 3D, see:

  "An Easier Interface"
  by Mark A. Clarkson
  BYTE, Februry 1991, pages 277-282
  Volume 16, Number 2

More next year :-)

-- Jecel


Click here to return to the Tunes UI mail archive.

Click Chris -- chharris@u.washington.edu hi.tar000644 057164 000036 00000000000 05722306112 013003 0ustar00chharrisuser000000 000000 index.html000644 057164 000036 00000002775 05712635223 014032 0ustar00chharrisuser000001 2207253 The Tunes UI Mail Archive

The Tunes User Interface Mail Archive

(Last modified Saturday, January 28, 1995 @ 1:30PM PST)

The following are all the different UI threads I've been able to dig out of the archives, with the most recent on the top. (Each invidual thread is formatted so the oldest message is on top.) If you find any more that I may have missed, please let me know.

Note that some messages may have been edited, shortened or eliminated to make this work in the best way possible. I have tried my best to maintain the author's thoughts and writing as much as possible, but I can't be perfect, so there may be mistakes. Please let me know if you find any.

Being Politically Correct: Discussion of how to incorperate non-standard UI technologies.

Goals: Discussion about Chris' Proposed Goals

Cells: Mike's cell-based UI ideas. Evolves into a small discussion about transparency.

Coordination: Chris' volunteering to be coordinatior.

Miscelaneous: a sampling from a number of different, mostly older threads about UI goals.


Click here to return to the Tunes UI page.
Page maintainer:
Chris -- chharris@u.washington.edu
misc.html000644 057164 000036 00000007326 05712636376 013655 0ustar00chharrisuser000001 2205130 Misc UI Thread

The Miscelaneous UI Thread

The Tunes User Interface Mail Archive

(Last modified Saturday, January 28, 1995 @ 1:30PM PST)
Date: Mon, 7 Nov 1994 23:48:28 +1300 (NZDT)
From: Johan Van Schalkwyk 
Subject: What's in a name?
Consider Windoze: we all know its a dog, its only advantage being that it is moderately less user-hostile than the programming atrocities that preceded it.. Why has it sold so well - (1) good marketing hype (2) it has certain attributes that are desirable - its clumsy GUI, its primitive multi-tasking, etc. (3) Microsoft have clout. Nevertheless, you cannot ignore its success.


Date: Mon, 7 Nov 1994 15:39:27 -0500
From: Cybernaut 
Subject: OFF: Extensible File System
I know there's a slight avversion to file systems in this project, but I just thought I'd pipe up with an idea I've been working on for a while. I call it an Extensible File System. Any file system I've yet encountered, FAT, HPFS, various UNIX FSes in particular can be made extensible. What this entails is adding additional tags to any directory entry for any file you want to entend. For instance, for graphics files, the tag can contain information about the format and structure of the image, resolution, aspect ratio, the best viewer for it, etc., etc. This would make prioriknowledge of the image file unnecessary. Also, for things like constructing GUI desktops, each dirent in the user's desktop directory could designate an object on the desktop. Each dirent could then have an additional tag describing where that object appears on the decktop, a pointer to a small graphic file to retrieve that object's icon, information on what needs to happen when that object is clicked, double-clicked, drag-and-dropped, etc.

I believe that by handling objects files as just another extended dirent tag, the system can easily discern one object from another and know what object does what without ever having to know where that object is stored or anything about the internal stucture of the object files.


Date: Mon, 7 Nov 1994 15:46:44 -0500
From: Cybernaut 
Subject: GOALS: My two cents worth.
You wanted one-liner goals for the project, well, here's mine:


Date: Wed, 9 Nov 1994 17:43:33 +0800
From: kyle@putput.cs.wwu.edu (Kyle Hayes)
Subject: Re: Goals Summary
End Users/Marketing Goals:


Date: Wed, 30 Nov 1994 23:23:30 +1300 (NZDT)
From: Johan Van Schalkwyk 
Subject: Charters & goals.
"Must be malleable / no set UI". Yes & NO!!

It is great to have a flexible system, but, let's face it, most people are creatures of habit. Present John Citizen with more than several options, and he will more likely than not crack wide open! Have a set UI that is so damn good that no one in his right mind would want to change it and then make it so easy to change that even Windows users can adapt it to suit their perverted needs!


Click here to return to the Tunes UI mail archive.

Click here to return to the TUNES UI subproject.


Page maintainer:
Chris -- chharris@u.washington.edu
pc.html000644 057164 000036 00000023240 05712635652 013311 0ustar00chharrisuser000001 2205310 Politically Correct UI Thread

Politically Correct UI Thread

The Tunes User Interface Mail Archive

(Last modified Saturday, January 28, 1995 @ 3:00PM PST)
Date: Mon, 2 Jan 1995 22:28:59 -0800 (PST)
From: Chris Harris 
I came up with a seemingly good idea for low-level UI stuff, which I'll descirbe below, and then complain about:

Below the set of UI modules, talked about last time, are the device drivers. These drivers are a set of objects representing the availible video hardware. (Ignoring audio stuffs at the moment, since they're a rather different type of device.) They include support for setting pixels, drawing lines and circles, moving pixmaps around in memory, and all that good stuff. Its happily set up with a neat inheritance hiarchy, to reduce code duplication, and all the calls are inlined, so its still fast.

Each UI module then works with one or more screen monitor drivers, providing the basic stuff they'd probably all need to use. For sub-UIs, virtual monitor objects would be created, that would be mapped into the space of the real video hardware.

(Sorry if this sounds stupid; I need to go to sleep soon.) This is all fine and dandy, but it seems that its a bit biased. For one thing, its rather two-dimensional, so a 3d interface would have an unhappy burden mapping a 2d screen onto a flat surface. (It'd also be silly for one 3d interface to enclose another, since the second one could only exist on one surface of the first.)

That might be okay, since the screen really isn't 3d in the first place. But that's not all the problems.... What if we wanted the UI to be able to be run from an X terminal? (Not an unreasonable idea....) X provides a few more services than those described above, so an X driver would be under-used, or the different UIs would have to go out of their ways to support such a thing. (This would get bad if all the availible UIs had the same x-supporting code....)

Anyone have any suggestions on how to expand this model to be more pollitically correct? =)

-Chris


Date: Tue, 3 Jan 95 19:20:19 MET
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Poor you ! You'll be suffering my "freedom" motto on UI's too :)

Below the set of UI modules, talked about last time, are the device drivers. These drivers are a set of objects representing the availible video hardware.
Why support only video interfaces ? What if the system is not used with a screen, or used by the blind ?

I agree we shall support such video interface, because they are common, cheap, handy, well known, and knwon to most current computer users and programmers, including ourselves.

But we're not interfacing just the hardware. As a programmer, I hate to say, "draw a window," "show such object at such position," "put a button here." What I want is say, "Here, let the user choose an arbitrary object of such type/fulfilling such conditions." That some textual no-edit input is used, or a textual editable screen, or a window-based interface, or a voice-based interface, or a pre-programmed script, or whatever be actually used, I just don't care.

What *I* want is a proper object to continue computations. I'll say to the interface, "Hello, this is me; could you please give me an object with such properties?" and the interface would do something, and say, "Oh, yes, here it is !" I, or a standard library, or the user, or a combination of those, would then invoke standard and/or programmer/user configurable *constructors* that manage to create such an object from more basic objects like keyboard and screen, or a script file, or a joystick, or whatever.

As the caller is recognizable, I could do both caller and callee specific configuration (e.g. the user wants a window with a blue border, and the program uses a flashing red background because it's an alarm).

(Ignoring audio stuffs at the moment, since they're a rather different type of device.)
Again, why focus only on screens ? U.I. stuff, like any object in the system, should always be actually dependant only on stuff it really should depend on. If you just wanna input a natural number below 1000, don't ask "draw this and that", just ask a natural number below 1000); if you want to use vietnamese words, let the U.I choose some audio device and/or use some text device with a vietnamese character encoding; that the device itself would go through multiple other modules, you don't care, and this won't affect data throughput, as all calls to will be inlined as needed.

Anyone have any suggestions on how to expand this model to be more pollitically correct? =)
I completely agree on what you say about the video-specific part of the UI. We shall provide such video drivers (or use existing ones, e.g. X-Window, Windows, MacOS). But in no way should our U.I. be video specific. The same program, unless it needs video animation (e.g. video games) or other interface specific stuff, should run on any computer running our system. And even if the actual hardware does not exist, the user should be able to virtualize it (e.g. redirecting to /dev/null) so as to run any program, even if the program requires specialized hardware.


Date: Wed, 4 Jan 95 0:06:46 MET
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
I worry that, in trying to be very general, we loose all our speed.
Don't worry about that. I have many ideas about how we can can have fast interfaces, though again, the user should be free to parametrize his interface as he pleases, and to use whatever concept he pleases, chosing from the ones provided, or creating his own.

For instance, I like the idea of manipulating a visible stack of any kind of objects, as on HP calculators; nothing would prevent users to have multiple stacks, as stacks are themselves objects. I feel that the standard "cut©" paradigm from the MacIntosh (or worse -- X-Window), is just some very limited kind of one-level deep stacks, of untyped ASCII text only in the case of X-Window, and weakly typed loosely managed objects but for a limited number of system types in the case of MacOS or MS-Windows.

As for structure editing, (parametrizable) visual constructors/editors could be automatically derived from the structure of an object type. The programmer and/or the user could override the defaults by specifying what kind of editor he wants under various conditions depending on the program that asks an object and/or [?]

Now, when a program *really* wants direct access to some hardware (e.g. movie decompresser/player), then there's no need for nasty interfaces; just grant direct access to the real or virtual (multiplexed) pixmap hardware. KISS means do not introduce software interfaces when they are not yet or not anymore needed.

Please find me an example (but displaying raw images) where it truely useful that the programmer knows that the user will have such button at such pixel position and not one pixel higher, lower, more on the right or the left, brighter or duller, more red or more blue, etc.

As far as I know, when a program needs an object of some type, it needn't know how the object was synthetized, though in current systems the programmer will typically have to provide an editor himself as the system won't allow such synthesis otherwise.

Where does our specificity come from? It is this that we need to design...
To me it comes from this modularized design: do not put in a program what does not belong to it, but instead, provide separate interfaces, and generate interfaces automatically while allowing easy annotation of a program by sample customizable interfaces.

Of course, I'm not the UI guru or maintainer, so rather ask Chris about the detailed look and feel of the standard system interfaces provided. I'm just giving away my two pence worth.


Date: Tue, 3 Jan 1995 16:13:03 -0800 (PST)
From: Chris Harris 
Fare-

Okay, I'm definitely sold on your ideas. Guess I've been thinking about the different levels seperately, rather than as a whole unit. (Seems to be the same problem folks are having with the LLL debate the kernel vs compatible objects view.) If this could be successfully implimented, this OS would be (one of) the easiest to develop for in the world, hence making people want to write lots of apps. =) Could even port the standard libs to some evil OS (like NT/DOS/Chicago) or some decent, but not perfect, OS (like Linux), to try and get more apps.

Guess my job for now (other than learning about video programming and pondering the standard objects) is to look at what devices we want to initially consider, and what different operations a decent/good/incredible UI would be able to do on these devices. (All this on my first day back to school too. =) If you've already done some of this pondering, please let me know.

Anyone have any problems with my blankly accepting Fare's work on this? Mike, this looks like a good time to inject a "but this can't be done efficiently" comment. =)

Hope you're not having too much trouble recovering from all yer New Years parties.... =)

-Chris


Click here to return to the Tunes UI mail archive.

Click here to return to the Tunes UI subproject.


Page maintainer:
Chris -- chharris@u.washington.edu
nitor drivers, providing the basic stuff they'd probably all need to use. For sub-UIs, virtual monitor objects would be created, that would be mapped into the space of the real video hardware.

(Sorry if this sounds stupid; I need to go to sleep soon.) This is all fine and dandy, but it seems that its a bit biased. For one thing, its rather two-dimensional, so a 3d interface would have an unhappy burden mapping a 2d screen onto a flat surface. (It'd also be silly for one 3d interface to enclose another, since the second one could only exist on one surface of the first.)

That might be okay, since the screen really isn't 3d in the first place. But that's not all the problems.... What if we wanted the UI to be able to be run from an X terminal? (Not an unreasonable idea....) X provides a few more services than those described above, so an X driver would be under-used, or the different UIs would have to go out of their ways to support such a thing. (This would get bad if all the availible UIs had the same x-supporting code....)

Anyone have any suggestions on how to expand this model to be more pollitically correct? =)

-Chris


Date: Tue, 3 Jan 95 19:20:19 MET
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
Poor you ! You'll be suffering my "freedom" motto on UI's too :)

Below the set of UI modules, talked about last time, are the device drivers. These drivers are a set of objects representing the availible video hardware.
Why support only video interfaces ? What if the system is not used with a screen, or used by the blind ?

I agree we shall support such video interface, because they are common, cheap, handy, well known, and knwon to most current computer users and programmers, including ourselves.

But we're not interfacing just the hardware. As a programmer, I hate to say, "draw a window," "show such object at such position," "put a button here." What I want is say, "Here, let the user choose an arbitrary object of such type/fulfilling such conditions." That some textual no-edit input is used, or a textual editable screen, or a window-based interface, or a voice-based interface, or a pre-programmed script, or whatever be actually used, I just don't care.

What *I* want is a proper object to continue computations. I'll say to the interface, "Hello, this is me; could you please give me an object with such properties?" and the interface would do something, and say, "Oh, yes, here it is !" I, or a standard library, or the user, or a combination of those, would then invoke standard and/or programmer/user configurable *constructors* that manage to create such an object from more basic objects like keyboard and screen, or a script file, or a joystick, or whatever.

As the caller is recognizable, I could do both caller and callee specific configuration (e.g. the user wants a window with a blue border, and the program uses a flashing red background because it's an alarm).

(Ignoring audio stuffs at the moment, since they're a rather different type of device.)
Again, why focus only on screens ? U.I. stuff, like any object in the system, should always be actually dependant only on stuff it really should depend on. If you just wanna input a natural number below 1000, don't ask "draw this and that", just ask a natural number below 1000); if you want to use vietnamese words, let the U.I choose some audio device and/or use some text device with a vietnamese character encoding; that the device itself would go through multiple other modules, you don't care, and this won't affect data throughput, as all calls to will be inlined as needed.

Anyone have any suggestions on how to expand this model to be more pollitically correct? =)
I completely agree on what you say about the video-specific part of the UI. We shall provide such video drivers (or use existing ones, e.g. X-Window, Windows, MacOS). But in no way should our U.I. be video specific. The same program, unless it needs video animation (e.g. video games) or other interface specific stuff, should run on any computer running our system. And even if the actual hardware does not exist, the user should be able to virtualize it (e.g. redirecting to /dev/null) so as to run any program, even if the program requires specialized hardware.


Date: Wed, 4 Jan 95 0:06:46 MET
From: rideau@clipper.ens.fr (Francois-Rene Rideau)
I worry that, in trying to be very general, we loose all our speed.
Don't worry about that. I have many ideas about how we can can have fast interfaces, though again, the user should be free to parametrize his interface as he pleases, and to use whatever concept he pleases, chosing from the ones provided, or creating his own.

For instance, I like the idea of manipulating a visible stack of any kind of objects, as on HP calculators; nothing would prevent users to have multiple stacks, as stacks are themselves objects. I feel that the standard "cut©" paradigm from the MacIntosh (or worse -- X-Window), is just some very limited kind of one-level deep stacks, of untyped ASCII text only in the case of X-Window, and weakly typed loosely managed objects but for a limited number of system types in the case of MacOS or MS-Windows.

As for structure editing, (parametrizable) visual constructors/editors could be automatically derived from the structure of an object type. The programmer and/or the user could override the defaults by specifying what kind of editor he wants under various conditions depending on the program that asks an object and/or [?]

Now, when a program *really* wants direct access to some hardware (e.g. movie decompresser/player), then there's no need for nasty interfaces; just grant direct access to the real or virtual (multiplexed) pixmap hardware. KISS means do not introduce software interfaces when they are not yet or not anymore needed.

Please find me an example (but displaying raw images) where it truely useful t