Date: Mon, 2 Jan 1995 22:28:59 -0800 (PST) From: Chris HarrisI 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 HarrisFare-
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 subproject.