Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: (Yet another) Suggestion for 1.4
Message-ID: <2428@amiga.UUCP>
Date: 16 Jun 88 04:13:29 GMT
References: <611@myrias.UUCP> <62300005@hobbiton> <2122@sugar.UUCP> <582@cord.UUCP>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Distribution: na
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 129

In article <582@cord.UUCP> nsw@cord.UUCP (59455-N Weinstock) writes:

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

If you'll settle for a scrolling list that pops up, this is the plan
for Commodities Exchange (CX).

If a program can arrange to lay low (we'll need some conventions on the
user interface here), hang around waiting on a port, then with CX it is
easy to:
1- wake up in response to a hotkey which the user can re-assign at run time
2- wake up when the user selects explicitly so in a scrolling list
  of CX clients.

It is also easy for the clients to do input-specific stuff, like
turning off the capslock bit (our favorite), keyboard translation, etc.,
but perhaps the most useful role will be as a common controller for things
that can "pop up."

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

No comment.



)Anyway, I envision the following system:

Let me translate to CX...

)1)  User runs application "FooBar" (either from startup sequence or whatever)
Many things from future "startup drawer" on WB, I hope.  CX also presses
for a standard for TOOLTYPES as arguments, for things like initial hotkey
selections.

)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).
Calls a function of commodities.library to create a client representative
(a 'broker').  Provides a name, description, its list of tooltypes for
run-time editing of parameters (using the CX controller), and maybe a hotkey
(or other input thingies) preferably based on the tooltypes.

)3)  Workbench replies to FooBar's reply port indicating that the menu item is
)	successfully installed.
Well, functions return synchronously with creation of thingies, no big deal.

)4)  FooBar makes itself invisible, does it's foobar-like things.
Programs may or may not fire up  with open windows, depending, I hope,
on the tooltypes.

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

A "master" hotkey brings up a controller program which allows viewing,
disabling, and parameter editing of the clients.  Editing is like
a better version of WB Info, with Save/Use/Cancel.  One option of
the controller is to send a message to the client port when the user
selects the Client's name and clicks something like "Poke Him."

Hotkeys can also cause a poke, and it can be easily arranged that
a poke arrives if the user tries to start a program a second time,
that is, the program pops up if its WB icon is double clicked on, whether
resident already or not.

)Or, the original 
)FooBar menuitem may have pointed to a submenu, in which case the user selected a
)specific action for FooBar to do.

Well, the Save and Use options for editing the tooltypes within the
controller send a "parameter update" message to the client, which then
probably frees all of its thingies, and reinitializes using its
startup-up code again, with a new parameter list of tooltypes.

I haven't thought of having the controller be able to send commands
as such, but it's a concept.


)When FooBar is going to exit, it sends another message to Workbench telling it
)to remove the menuitem. 

DeleteAllCxObj( broker );

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

The former.

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

Well, I'll admit that it would be nice to hook into the workbench, but
the pop-up window and scrolling list can do more, including pop up
on any "shared" screen, following the standard some BIX guys (esp. Willy
Langeveld) are trying to work out.

)Comments?  Is this a job for IPC?

Well, messages are IP and in this case they C.

>Is this too much like M*c desk accessories ?

Nope.

) Has anyone implemented something like this?

Almost, almost.  The controller is under way, the protocol for
passing up your tooltypes (esp. Save) is maturing in the design phase,
and the rest is done.

)|  Neil Weinstock | ihnp4!cord!nsw   | "Hey you kids! Get out of my |

	jimm
-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.