🚀 go-pugleaf

In article <123@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>In article <582@cord.UUCP> nsw@cord.UUCP I wrote:
>> [Suggestion for a public hook into the Workbench menu strip]
>
>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

Well, I wasn't really following up Peter da Silva's article;  I was instead
following up a previous article where the poster complained about having
all these windows hanging around *while the programs are running*.  My
proposal attempts to address that issue, not the issue of being able to
run programs from a menu, which Browser seems to have implemented.
(And could be done under my system, see below).

I mean, let's say I run Dmouse from my startup sequence, but later on I want
to modify certain options?  This way I just pop up a Workbench menu which
lets me call Dmouse and talk to it.  It also gives me a quick way to find
out what programs are lurking around the system without having windows
cluttering up the Workbench.

>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

Sure, programs would have to be written (and rewritten) specifically to deal 
with it.  But the interface I described is very simple (i.e. I can understand
it :-), and setting up one message port really isn't that big a deal, is it?
There's certainly not going to be much traffic from it.

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

The ability to load and run new programs from a menu is a separate feature
which is also useful.  Now consider that it could be implemented using the 
system I described:

You would have to create a server which would be run from your startup sequence.
The server looks in a configuration file and creates the appropriate menuitems
for the applications you will want to have access to.  This server then links 
the menuitems into the publicly accessible Workbench menu.  Now, when the user 
selects one of those menu items, the server gets a message.  It can then go 
and fire up the application itself.  Voila!  You only need one program (the 
server) to stay loaded all the time, and your system is fully implemented and 
integrated into Workbench.

The public menu hook makes lots of neat things like this possible.  I just
don't know if it can be added on to Workbench as an aftermarket accessory,
or if it would have to be official from C-A in order to avoid resorting to
illegal hacks.

>-Peter Schachte

.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...
|  Neil Weinstock | ihnp4!cord!nsw   | "I think my cerebellum just  |
|  AT&T Bell Labs | nsw@cord.att.com |      fused." - Calvin        |
.- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...