MUSIC revision -INFINITY

[ANDREASA@dhhalden.no]

> Welcome to:
>
>         MUSIC - MOOSE USer InterfaCe

Good name for it.

> 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.

This is exactly what I feel.

I agree with part I.

> 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.

I have been looking on a solution very similar to this, even though I maybe
have elaborated it more so please read.
I work with the graphics part, or have done so far. I have thought up a set
of classes. One of these classes is a window class (fantastic isn't it :-)
that has a number of functions of the type CloseIconClicked, MenuToggeled
etc. These functions will do the events transparent, and the developer don't
even need to know that the system is event driven.
The constructor in a class will take all event functions and put them in
lists. These lists will be mantained by the device drivers.
The mouse driver will mantain a list of functions, pointer to functions
actually, and whenever there is a click event, it will traverse its list
of items/functions that responds to a click, and when the mouse driver finds
an item that lies within the area of the mouse click, it will call the
functions.
How effective this will be, I admittably don't know, and I'm not sure I want
to know either. I'm affraid that having all input-devices scanning lists
all the time will be pretty time consuming.
Of course I have thought of this too :-)

(Mouse) Device Driver Item List
   |
   ------------------------------------------------ <- Window-list
            |
            | <- A window
  -------------------------------
  | <- Button  | <- ScrollBar   | <- Another Window
  0            0                |
                                |
                            --------- More Items...


Whenever the driver finds which Window-list the element are in, it starts to
traverse the windows "private" list for the items in this window, til it
finds an item, or til it finds out that the main window should have the
message.
How does this sound, a tree like structure in way?
This could be enforced for mice, keybords, com-ports, parallell-ports etc.
Only the type of classes will be important. The com-port device will have
a com-port class.
This list type thing could be implemented in at least one other way, that
might be better because it don't lend itself to much upon the driver, and
it is more OO, but the structure itself will mainly be mantained.
The driver has a list of pointers to objects, and the objects have pointers
to other objects inside themself. A recursive definition that will decrease
the work for the device driver.

> 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.

I'd rather put the owner rights into the main window. Then the main window can
ask it's childs for access to a resource. In addition I assume that there will
be functions for some sort of dual piping/dynamic information interchange, so
that one window can ask another window (even in another machine..., at
another part of the world..., or even in the space shuttle... :) for
information. This could include any type of information/data.

IV.

I can't say I agree very much with that part. I see the objects, but I'm not
sure that it is as much OO as possible. Lets discuss this part because
I'm not sure what's the best method, the Mac way, the NeXT way or the way
presented her.



V. Resource requirements for the GUI. Was: V. What is missing
Since this will be a GUI, the minimum display will be graphical. Now do we
think it is neccesary to support Hercules, CGA, EGA, PGA, MCGA? I say no.
If it is going to be a gui, the user will need all space he can get on his
screen, else there will be no place for him to do what he really wants.
Therefore I say minimum VGA resolution. But there are more things than
resolution to things. Colors are equally important. I see myself writting a
GUI with about 16 reserved colors, that a user can't alter (easily).
So if he wants to display a picture, he will have to use the system palette,
if he don't want to screw up the screen of course. Dithering will not be
satisfying because we need one color with several different brightnesses,
say 4 shades of gray a couple of shades of blue etc. So I say minimum SVga,
if that is ok for you of course. I belive that almost everybody that have a
386 also have a SVga card. This will give us 256 colors, minimum for any card.
If you really want, I can do some codeing for vga to, but it will be without
any joy...:-\
Flame of if you feel for it. I can take it (I hope :-)


VI. Design specifics.
Guideline no.1
The screen is a resource. The user has got a limited amount of it, therefore
the gui should enforce programs not to steal this screen area. The gui in
itself should not take more place than is neccessary.

Idea no. 1
Caption is the most unimportant tool in a window. A caption steals valuable
resources. So does the menu. The "best" way is the Mac way/the X-way, but it
isn't especially OO/easy. Therefore I suggest that we combine the menu and
the caption into one toggelable line, as the Amiga OS does.



VII. What is missing
Same as V. in last message :-)

type flames.txt  > andreasa@dhhalden.no

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--