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