Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!ucbvax!decwrl!labrea!sri-unix!quintus!pds
From: pds@quintus.uucp (Peter Schachte)
Newsgroups: comp.sys.amiga.tech
Subject: Re: (Yet another) Suggestion for 1.4
Summary: How is this better than the original suggestion?
Message-ID: <123@quintus.UUCP>
Date: 16 Jun 88 22:43:17 GMT
References: <611@myrias.UUCP> <62300005@hobbiton> <2122@sugar.UUCP> <582@cord.UUCP>
Sender: news@quintus.UUCP
Reply-To: pds@quintus.UUCP (Peter Schachte)
Distribution: na
Organization: Quintus Computer Systems, Inc.
Lines: 52

In article <582@cord.UUCP> nsw@cord.UUCP (59455-N Weinstock) writes:
>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.

This looks reasonable.  But how is it better than the (simpler) suggestion
you are following up?  It has the advantage that the menu can be quite
dynamic.  Programs can change it around all they like, on the fly.  But
this doesn't seem like such an important feature.  And it has the
disadvantage of requiring programs that are to take advantage of WB menu
to know all about it, and set up message ports and so on.  This
seems quite undesirable to me.  I'd like to be able to put lots of nifty
PD programs, particularly filters, into my WB menu.  And compilers,
linkers, and assemblers.  Without having to rewrite them to handle this
stuff.  And finally, this would require that any program to be included
in a menu be loaded.  If I want my compilers, linkers, and assemblers
to be included in the WB menu, that's going to use up quite a bit of
memory.

I think a system based on a single file enumerating your menus, items,
and subitems, what they do, and what arguments they expect, would be
quite workable and simple to use.  There are a lot of details to work
out; for example, how to specify arguments other than files to a
menu-fired program.  This approach could lead to a super-WB, capable
of running non-WB programs as well as WB programs.

Again, your idea seems like a reasonable way to have a menu strip not
associated with any window.  But it doesn't seem to fill the role of
a way to fire applications from WB menus, which is what the article you
were following up was suggesting.

Another way to accomplish what you are after in the context of a WB
menu that can run arbitrary programs would be for your process (let's
take dropshadow as an example) to have a public message port, and to
have a separate program that would parse command-line switches and
compose a message to the public port, and then exit.  This would
also have the advantage that, if done properly, other programs
(AREXX comes to mind from out of nowhere) could use the port however
they wanted, too.  Anyone could write a program to modify dropshadow's
parameters with any interface they wanted.

Comments?
-Peter Schachte
pds@quintus.uucp
..!sun!quintus!pds