Path: utzoo!mnetor!uunet!husc6!rutgers!lll-lcc!lll-tis!ptsfa!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga
Subject: Re: Workbench and object-oriented programming (was Re: Iconification)
Message-ID: <4883@well.UUCP>
Date: 2 Jan 88 09:01:35 GMT
References: <1076@sugar.UUCP> <2826@cbmvax.UUCP> <1103@sugar.UUCP> <867@rocky.STANFORD.EDU> <487@cresswell.quintus.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 85


Article 12299 of comp.sys.amiga:

|> Has anyone else noticed that the Workbench is a rudimentary Object-Oriented
|> system?
|
|Sure.  The workbench, of course, is a rip-off of the Mac user interface.
|This was a rip-off of the Xerox Star (now called viewpoint) document
|processing system.  Star, I believe, grew out of work done at Xerox ...

Ah, Xerox, of course.  Should have known.  I only noticed the
object orientedness of the Workbench after I started reading "SMALLTALK-80
The Language and its Implementation," by the folks at Xerox PARC.

|> [ I talk about possibly using a "fakedisk.device" to get more power into
|>   the existing Workbench.  A "printer" icon, for example ...]
| ...What you really want it to do
|is to "send a print message" to the file.  This might mean firing up a
|printing program specific to that file that would do all the right
|things.

|> What you really want to do is write a tool called "print" that looks up
|> "PRINTER" in the ToolTypes array and fires off the named program when
|> you shift-double-click it. Then we want to beat C= into implementing the
|> drop-an-icon-onto-a-tool method of firing off programs.
|
|Sounds great!  Another thing that would be really useful is to have a
|COPY tool that is invoked when someone drags an icon into a drawer.
|This would be necessary for someone to bundle files into groups with a
|single icon.  E.g., a text file and a backup version of it.

Hmmm.  The problem with the "ToolTypes" method is having a standard way of
doing "interprocess communication."  Certainly every word processor has a
"Print"-like menu item or items, but how many have a way to receive a
"print" MESSAGE?  The only path I can see is to adopt/establish a standard
(with all that implies) method for interprocess communication.  One message
passing standard is the device IO request blocks, but this would mean having
everything look like a device, even word processors, which seems a little
strange.  AREXX supposedly provided a method for interprocess communication
that might be standardized - anyone have more info on that?

The best but hardest choice is to make the Workbench the full object
oriented system it was meant to be.  Since this model requires that the
objects interact by passing messages, and the objects are implemented as
tasks, some standard way of intertask message passing would be a given.
Needless to say, I think this is the way to go.

|A related issue:  is it possible to have a different set of menus and
|menu items for different file icons?  Then, as long as you could do the
|first thing I asked for above, you could at least have a "print" menu
|item appear in some menu when you had selected a printable file.  This
|would give a great degree of user extendability to the workbench.

Yes, this would be great.  This would be following the object oriented path
to its logical end, since the icon-specific menu items are just the set of
"messages" that that object can respond to.  The Workbench does this
already, to a limited extent by disabling (ghosting) innappropriate menu
items for the currently selected icon.  The "Empty Trash" item, for example,
is only enabled while a "Garbage"-type icon is selected.

It would then be possible to have user-programmed icons hanging around on
the Workbench that could get their own menu selections on the Workbench
screen when selected.  My hypothetical "Printer" icon could be controlled
directly from the Workbench by making it an object that responds to some
messages that are added to the Workbench menus, such as "Stop," "Start,"
"Abort," "Flush Buffer," or whatever control messages would be useful for a
print spooler.

|> The workbench is about 25% of a great tool....
|
|I know it's traditional for programmers to eschew icons and such for
|development purposes, but I think many might be converted if the other
|75% of the workbench were there.  It works as it is, but it really
|needs LOTS more generality.

I really think it's closer than that.  *Most* of the design is geared
towards an object oriented approach already - just a little eyes-open
redesign would be needed to put in the necessary hooks for user
expandability.  Once that's there, the Amiga programming community will be
able to fill in any blanks.  They've (or *You've* :-) done it already with
the other expandable parts of the system with such gems as ConMan, rrd's,
shells, and Ewhac-hacks :-).

		Stuart Ferguson
		Action by HAVOC