Menu sharing allows Frontier to send a set of menus to another application.
There are two sides to a menu sharing connection: a server and a client. The menu sharing server, Frontier, stores menus and allows script writers to edit them. The menu sharing client displays the shared menus.
When the user selects a command, the client application sends a message back to the server indicating which item was selected.
Menu sharing builds on top of the System 7 Component Manager, which handles the connections between the applications.
Menu sharing is a standard
It's supported by most major Mac applications that are scriptable. This includes Netscape Navigator, Microsoft Internet Explorer, BBEdit, Fetch, Anarchie, Eudora, StuffIt, Quark XPress, Metrowerks and Symantec development environments, and with the OSA Menu extension, the Macintosh system Finder.
Other applications can easily support menu sharing. The Menu Sharing Toolkit is provided is free and without royalty. It comes with full C source code, documentation and a sample application. Look in the Menu Sharing Toolkit sub-folder of the Toolkits folder in Frontier SDK. Many people find that it takes a single build to get menu sharing into their apps. It's really simple to support.
It's especially important that HTML editors support menu sharing as BBEdit does. It makes it possible for Frontier to add the glossary database, macros, and other automatic features to the HTML building process. These are very important features for web developers.
If you use a product that could benefit from menu sharing support, send an email to the developer respectfully asking them to take a look at this page. Thanks!
Frontier's Menu Editor
One of Frontier's capabilities is that it gives script writers an easy way to edit the contents of its own menu bar. When the user selects an item from the menu, Frontier runs the script that's linked into the menu item. To edit Frontier's menus, choose the Menu Bar Editor command from Frontier's UserLand menu.
Menu sharing extends this capability so that script writers can add commands to the menu bars of compatible applications.
For example, to edit Netscape's shared menu, Cmd-J to system.menubars.MOSS. MOSS is the creator identifier of the Netscape application. Once there, Frontier's outline editing commands work. This method works for all menu-sharing client applications.
Frontier 4.0 ships with sample menu bars for Eudora, Netscape, Microsoft Internet Explorer, the Finder and BBEdit; and UserLand's BarChart, DocServer, MacBird, and uBASE.
How it's seen in the client
Menus sharing adds a set of standard Macintosh menus at the end of an application's menu bar. Usually there's just a single menu called Scripts.
Script writers can add commands to these menus using Frontier. Any changes to the menus are automatically visible as soon as the script writer switches back to the client application.
Menu sharing does not in any way alter the performance of an application's menu commands, it just adds new commands to its menu bar.
Menu sharing allows script writers to view an application as a customizable development platform. They can add commands that automate an application just as if it had an integrated scripting language. Scripts can easily launch other applications and integrate their capabilities with the program and the Macintosh operating system.
Script users, who can be less technical than script writers, will see simpler commands in these menus. Examples include: prepare for a meeting, send a message to everyone working on a specific project; issue a press release; or hire a new employee. There are as many potential custom scripts as there are Macintosh users. They will only be aware that these commands were "put into" an application by a friend they work with, or their organization's network manager. The details of this technology are completely open to the script writer, but neatly hidden from the end-user.
By opening a product to menu sharing you offer more technical users an easy way to simplify your product for less technical users. This means your technology is more useful to a much larger number of people, and can only contribute to making your product more competitive and more profitable.
No Royalty or License Fee
There is no royalty or license fee for use of the Menu Sharing Toolkit. It's provided in source form so that developers know exactly what the Toolkit is doing on their behalf, and so it can easily be adapted to different development environments.
You may include this code in any Macintosh application, but you must maintain our copyright notice at the head of each UserLand-supplied source file.
Menu Sharing is Open
We're publishing source code for the client side of the menu sharing protocol, and plan to support menu sharing in all future versions of UserLand Frontier and all other software products developed by or published by UserLand Software.
We believe menu sharing should be an open specification, with freely distributed source code. Everyone wins if it's widely supported on both sides of the equation, by clients (the vast majority of "sharing-aware" programs) and by servers (Frontier, and competitive products).
Icing on the Cake
It makes little or no sense to add menu sharing if an application is only minimally Apple Event-aware. Scripts launched from a shared menu bar must be able to call back into the program to open or close a window, get a value, add a record, dial the phone -- basically to do the types of things the program was designed to do.
Menu sharing, therefore, is like icing on a cake. Once you've added a reasonably complete set of scriptable messages, the next step is to open up your menu bar to allow script writers to insert new commands that are implemented in scripts.
The readme file in the Menu Sharing Toolkit folder includes a step-by-step cookbook on adding menu sharing to a C application; reference information; and a history of the evolution of the protocol, dating back to 1992.
In order to be menu sharing-aware, an application includes the Menu Sharing Toolkit and inserts calls to Toolkit routines in several places: on initialization; in the main event loop; before processing a menu selection and where the user presses cmd-period.
Menu Sharing Toolkit 4.1
You can download the latest release of the Menu Sharing Toolkit from:
Doug Baron, firstname.lastname@example.org says:
The fundamental change (and the motivation for the update) is to allow clients to cleanly handle a server (i.e. Frontier) crash. Along the way we got a new feature that you might be interested in. (I know that Rich Siegel wants it for BBEdit.)
The new features are in effect only if the new SDK is used and Frontier 4.1 or greater is running. Here are the changes:
- If the menu sharing server crashes, the SDK will now clean up safely and remove the shared menus.
- There are two new optional callbacks: insertmenus and removemenus. The new calls SetMenusInserterCallback and SetMenusRemoverCallback can be used to provide your own routines. They both take a hdlmenuarray.
- Menus are now allocated in the client's heap zone. I don't know whether or not this makes any difference, but I thought it might avoid potential compatibility issues.
The new SDK is entirely backward compatible with older versions of Frontier. The matching changes in Frontier are entirely backward compatible with older versions of the SDK. I've tested the new SDK with both a 68K and PPC build of MenuSharer, running with both 68K and PPC versions of Frontier, 4.1 and 4.0.1.
© Copyright 1996-97 UserLand Software. This page was last built on 5/7/97; 1:36:34 PM.
It was originally posted on 5/5/96; 12:08:40 PM.
Internet service provided by Conxion.