Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!mtunj!io!granjon!edsel!packard!cord!nsw From: nsw@cord.UUCP (N Weinstock) Newsgroups: comp.sys.amiga.tech Subject: Re: (Yet another) Suggestion for 1.4 Summary: Oh, yes, you can have it all Message-ID: <584@cord.UUCP> Date: 17 Jun 88 17:26:25 GMT References: <611@myrias.UUCP> <62300005@hobbiton> <2122@sugar.UUCP> <582@cord.UUCP> <123@quintus.UUCP> Reply-To: nsw@cord.UUCP (59455-N Weinstock) Distribution: na Organization: AT&T Bell Laboratories, Liberty Corner Lines: 74 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 | .- -- .. --. .- .-. ..- .-.. . ... .- -- .. --. .- .-. ..- .-.. . ...