coord.html 000644 057164 000036 00000005140 05712635513 014015 0 ustar 00chharris user 000001 2207250
Date: Wed, 21 Dec 1994 11:09:58 -0800 (PST) From: Chris HarrisSpeaking of fun, do we have a UI project coordinator? If not, I'd be happy to volunteer. =)Subject: MISC: Multi-level thinking/development
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 PrinceOn Wed, 21 Dec 1994, Chris Harris wrote:Subject: Re: MISC: Multi-level thinking/development
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/developmentChris-
I second your proposal of yourself as UI co-ordinator! Good idea.
JVS.
Click here to return to the Tunes UI subproject.
Date: Tue, 27 Dec 1994 23:14:44 -0800 (PST) From: Chris HarrisHere'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
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.
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:
Date: Wed, 28 Dec 1994 15:24:04 -0800 (PST) From: Mike PrinceOn Tue, 27 Dec 1994, Chris Harris wrote:
I fully agree with modularity and expandability.Goals/Proposal
[snip]
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 endThis 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 HarrisOn Wed, 28 Dec 1994, Mike Prince wrote:
On Tue, 27 Dec 1994, Chris Harris wrote:check.
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: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.)HelloWorld: // cell name "Hello World!" PrintString return Main: // another cell name [ "Explicit print" PrintString "HelloWorld" CALL ] UI endThis 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).
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 PrinceOn 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*" -printjust 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-0very 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 Chris -- chharris@u.washington.edu hi.tar 000644 057164 000036 00000000000 05722306112 013003 0 ustar 00chharris user 000000 000000 index.html 000644 057164 000036 00000002775 05712635223 014032 0 ustar 00chharris user 000001 2207253
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.
Date: Mon, 7 Nov 1994 23:48:28 +1300 (NZDT) From: Johan Van SchalkwykConsider 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.Subject: What's in a name?
Date: Mon, 7 Nov 1994 15:39:27 -0500 From: CybernautI 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.Subject: OFF: Extensible File System
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: CybernautYou wanted one-liner goals for the project, well, here's mine:Subject: GOALS: My two cents worth.
Date: Wed, 9 Nov 1994 17:43:33 +0800 From: kyle@putput.cs.wwu.edu (Kyle Hayes) Subject: Re: Goals SummaryEnd Users/Marketing Goals:
Date: Wed, 30 Nov 1994 23:23:30 +1300 (NZDT) From: Johan Van Schalkwyk"Must be malleable / no set UI". Yes & NO!!Subject: Charters & goals.
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 subproject.
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.
(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