The following is a message Fare sent to Chris (and the other Tunes members) about his UI thoughts. Note that the grammar of his message had been edited slightly, as English is not his first language. (As if I know enough about it to be an editor. hehe....) The comments he is responding to will appear differentiated from the reply on any decent web broser.
From rideau@clipper.ens.frWed Jan 11 19:16:33 1995 Date: Tue, 3 Jan 95 19:20:19 MET From: Francois-Rene Rideau (rideau@clipper.ens.fr) To: Chris Harris (chharris@u.washington.edu) Cc: TUNES is a Useful Not Expedient SystemSubject: UI freedom (was: UI: Being Pollitically Correct)
Poor you ! You're suffering my "freedom" motto about 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 to 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.
-- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developer. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ /
Click here to return to the UI Subproject page.
Page maintainer: