Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mtunx!att!ihnp4!cord!nsw
From: nsw@cord.UUCP (N Weinstock)
Newsgroups: comp.sys.amiga.tech
Subject: Re: (Yet another) Suggestion for 1.4
Message-ID: <582@cord.UUCP>
Date: 15 Jun 88 15:10:16 GMT
References: <611@myrias.UUCP> <62300005@hobbiton> <2122@sugar.UUCP>
Reply-To: nsw@cord.UUCP (59455-N Weinstock)
Distribution: na
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 60

In article <2122@sugar.UUCP> peter@sugar.UUCP writes:
>Actually, he grabs a copy of my Browser from Fish Disk whatever or from his
>local sources archive, and adds the line:
>
>Tool;Workbench;sys:tools/toolname
>
>to his browser.tools file. Then whenever he wants to kick off that tool, he
>calls up the tools menu and selects that item...
>
>-- Peter da Silva      `-_-'      ...!hoptoad!academ!uhnix1!sugar!peter

This brought to mind some recent postings where people complained about all
the little windows belonging to various utilities (Dmouse, DropShadow, etc.)
which clutter up the Workbench screen.

I think that a really nice enhancement to Workbench would be a hook for 
application programs which are always hanging around to get into the Workbench 
menu strip.  A similar system is implemented fairly nicely on the AT&T 630 MTG 
terminal I use at work, and it eliminates those pesky windows.  Unfortunately,
I don't yet know enough about the guts of Workbench to know how difficult this
would be, but it doesn't *seem* like too big a deal (famous last words :-).

Anyway, I envision the following system:

1)  User runs application "FooBar" (either from startup sequence or whatever)
2)  FooBar sends a message to a special message port belonging to Workbench.
	The message includes a pointer to a menu item which is to be used
	by FooBar, but is to appear in a Workbench menu (maybe a new
	menu on the right, I don't know).
3)  Workbench replies to FooBar's reply port indicating that the menu item is
	successfully installed.
4)  FooBar makes itself invisible, does it's foobar-like things.

Now, whenever the user calls up this new Workbench menu, he sees a list of
applications which have installed themselves in the system. He/she selects 
"FooBar".  Now Workbench sends a message (using the reply port from the original
"install menuitem" message) to FooBar telling it that it was selected.  FooBar 
can then pop up a window, requester, or do whatever it wants.  Or, the original 
FooBar menuitem may have pointed to a submenu, in which case the user selected a
specific action for FooBar to do.

When FooBar is going to exit, it sends another message to Workbench telling it
to remove the menuitem.  If FooBar wants to change the menuitem it can remove
it and then install the new one, or send an "update menuitem" message to 
Workbench, which would then take another look at the menuitem and perform the
appropriate Intuition operations to update everything (FooBar always owns the
memory in which the menuitem is placed, Workbench only gets the pointer.)

So, there you have it.  All those neat little utilities which enhance Workbench
can become a *part* of Workbench, thereby cleaning up the Workbench screen
and adding flexibility to the system.  And the world becomes a better place.

Comments?  Is this a job for IPC?  Is this too much like M*c desk accessories 
(at least multitasking makes the interface clean)?  Has anyone implemented 
something like this?

.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...
|  Neil Weinstock | ihnp4!cord!nsw   | "Hey you kids! Get out of my |
|  AT&T Bell Labs | nsw@cord.att.com |  yard!"  - David Letterman   |
.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...