MUSIC revision -INFINITY

[JJ Lay]

JJ Lay said:
>From csjjlay Mon Feb 15 15:58:25 1993
Message-Id: <m0nODpV-000d51C@knuth.mtsu.edu>
From: csjjlay (JJ Lay)
Subject: MUSIC revision -INFINITY
To: ANDREASA@dhhalden.no, csjjlay@mtsu.edu, danodom@matt.ksu.ksu.edu,
	dmarer@td2cad.intel.com, duzan@cis.udel.edu, garfield@sra.com
Date: Mon, 15 Feb 1993 15:58:20 -0600 (CST)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3390      
Content-Length: 3390


Welcome to:

		MUSIC - MOOSE USer InterfaCe

What follows is a set of general guidelines for building the user
interface.  Feel free to flame me if I left out something
important (because I did).  This was written to help move this
group along in writing specifications documents.

MUSIC will be a completely graphical user interface.  There will
be no command line prompt whatsoever UNTIL the gui is finished.
This I feel is the fundamental problem with current OS's.  They
write and OS using a text command prompt and then slap the GUI
on next.

I. What the user sees
	All system objects will be represented as icons on the
	screen.  These include but are not limited to:
	* Data Objects
	* Directories
	* Executable Objects
	* Processes
	* Devices

	Processes communicate to a user via Windows.  Windows
	can hold: buttons, switches, text, etc.  i.e., anything!
	Windows can have menus: both pulldown and popup.

II. How the processes get input
	The user interface will be event driven.  The objects
	will each have a routine that will be activated when a
	certain activity happens to them.  e.g., a window sits
	idle until the user clicks on the "Close" icon.  The
	window's Close_window routine is then called.  Keyboard
	input goes to the current active window or the Interface
	Manager depending on the situation.

III. How processes create these objects
	There will be an Interface Manager that keeps track of which
	processes own which windows and icons.  No process will be
	allowed access to another's windows or icons unless certain
	rules are followed.  e.g., the Root Window that will hold
	all other windows and icons will be declared as SHAREABLE by
	the Interface Manager so that other processes can use it.

IV. Some examples of things one can do
	Say a user needs to email a text file but wants to run it
	through a text formatter first.  She would click on the
	text formatting program icon to bring up a menu of methods
	that this icon has.  She chooses "OUTPUT TO:" and then
	clicks on the email program icon.  She chooses the text
	formatting icon again and this time chooses "INPUT FROM:"
	and clicks on the document.  The text formatter then formats
	the document, pipes it to the email program which takes it and
	asks for a "Destination address", "Subject", etc. and then
	mails it.
	This implies a building block type approach to shell programs.
	Even complex applications that follow all the rules can be used
	in this manner.

V. What is missing
	Everything!  This is a rough idea of some of the things our user
	interface will (should?) do.  I emailed this severely lacking
	document only to get more ideas and feedback.  Am I on the right
	track?  What else should there be?

	

							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team



							------
							JJ LAY

------------------------------------------------------------------------
JJ LAY                                  CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST                    MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu                                             MTSU BOX 80
(615) 898-2658                                   Murfreesboro, TN  37132
------------------------------------------------------------------------
"I used to think that the idea of space probes was to answer questions.
That's hopeless.  You invariably raise more questions than you answer."
	-Andrew Ingersoll, Caltech, member of the Voyager 2 imaging team