🚀 go-pugleaf

In article <123@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>In article <582@cord.UUCP> nsw@cord.UUCP (59455-N Weinstock) writes:
>>[description of neat-o WB menu interface that uses ports and possibly IPC]
>
>This looks reasonable.  But how is it better than the (simpler) suggestion
>you are following up?  

Because it is far more flexible.  The previous suggestion was that the menu
items launch new programs (making it a shortcut to finding and double-clicking
a WB icon).  This would be nice, but Mr. Weinstock was interested not only
in making a shortcut to launching programs; he also wanted to eliminate 
extrac control windows on WB screen (ones that let you control the parameters
of a program or that have a close box to let you stop a background program).
He suggests that the WB menus are an ideal place to put these functions.

For example, consider DropShadow.  It has it's own window with sliders to
control darkness of shadow and height of windows (great program, by the way).
But this window gets in the way, and I don't like to see it.  DropShadow could
have a WB menu item that said "configure DropShadow" or something, and when you
pulled it, DS would open the window with the sliders.  It it could have a menu
"DS Height" with subitems for different heights, or some such thing.

Or, for example, if you have a screen-blanker, it could have a menu that
controls the blank interval, or other parameters.

Input handlers that munge the input chain could have WB menus that tell them 
to turn themselves on and off.

Of course, these things could be controlled by launching another program
that communicated with the program already in memory and told it to change
the parameters (like PopCLI does), but why should you have to load a whole
new program when all you really want to do is send a message to the program?

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

On the contrary, it does make that possible.  I envision the first program
that would use the WB menu interface would be one that sets up menus that
have program names in them, and when you pick those items, it launches the
appropriate program.  This program could look in a particular drawer for the
programs to put in the menu, or it could read a control file that told where
each executable can be found (you can be creative about how this is done).
Note that the programs are not actually loaded until the menu items are pulled.
All that is in memory is the program that set up the menus in the first place
and handle the program launches.

You can get even more sophisticated about this:  you can flag certain menu
items as "LAUNCH" menus that launch programs, and others as "MESSAGE" menus
that send messages to processes.  THere is a lot of flexibility here.

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

How is this any easier than having a message port for the WB menu messages?
It's just as hard to program, and now you have to have TWO programs, one
that stays in memory, and one that changes parameters.  Besides that, you have
to waste the time of loading another program, and possibly swapping disks in
order to get the one that has the control program on it.  And nothing STOPS
you from having it this way if you use the more powerful WB menu scheme.  You 
can STILL have a menu item launch a program if you want.  Thus you have 
compatibility with existing programs.

>Comments?

See above :-)

>-Peter Schachte

Davide P. Cervone
dpvc@tut.cc.rochester.edu
dpvc@ur-tut.UUCP
DPVC@UORDBV.BITNET