Tear-off, Float menus
Volume Number: 4
Issue Number: 4
Column Tag: C Workshop
Tear-off Menus & Floating Palettes 
By Don Melton and Mike Ritter, Impulse Technologies, Inc., Santa Clara,
California
Don Melton is the Computer Graphics Specialist for the San Jose Mercury News
and does technical support for the Knight-Ridder Graphics Network. His partner, Mike
Ritter, is a Research Scientist at Lockheed’s Palo Alto Research Laboratories in the
Electro-optics Department. In their spare time they do MacHacking for their own
company, Impulse Technologies, Inc.
Why TearOffPalette? Well, ever since we saw HyperCard we’ve been wondering,
just like everyone else, how Bill Atkinson did that impressive tear-off menu effect. Of
course, the wizardry Andy Hertzfield performed with Radius’s new monitors caught
our eye, too. If you haven’t seen Andy’s ROM-defying performance, take a look -- he
makes any menu tear off!
And now everyone wants to get into the act.
Daryl Lovato gave many of us our first clues toward making menus leave their
home in his article titled “Tear-Off Menus Explained” in December’s MacTutor. But
he still left many questions unanswered, like how do you get the darn palettes to ‘float’
above other application windows (which we call documents to differentiate them from
the floating palettes). And he didn’t use those stylish HyperCard title bars in his
palettes either.
We also noticed that all of the applications we saw which used tear-off menus had
some rather strange ‘features’ in them. Our first attempt to do the tear-off trick
simply mimicked HyperCard. The constant flashing of menu items soon drove us batty.
Then there’s Bill’s highlighting (or lack thereof) of his main window when a menu is
torn off.
Then we saw the new MacPaint. Sure, the highlighting is better but the palettes
are in a fixed order! Even HyperCard doesn’t do that. Two steps forward and one step
back. That’s progress.
If only Apple would just torture Andy Hertzfield until he lets them release his
code as system software. Alas, Radius has to maintain its market advantage. Maybe if
everybody buys enough Radius monitors Burrell Smith may let the cat out of the bag.
Fig. 1 Tear off palette menus that float on top!
Until then we decided to show you how it can be done. And how to make it nice
and modular too -- with one application, an MDEF and a WDEF. Using our code any
developer can implement tear-off menus and floating palettes in their application.
Really. As a bonus, our source code will also demonstrate how to:
• Work with MultiFinder using WaitNextEvent()
• Use Color QuickDraw to implement a full-color palette
• Respond to suspend/resume events
• Write a fully-working, albeit simple, grow zone function
And it has extensive error checking built right in. Enough to function correctly
with strict trap discipline and heap check, scramble and purge, all set in TMON, while
it runs con currently under MultiFinder with ResEdit and any Microsoft application.
Just about the nastiest environment a Mac developer could imagine.
It also (ta da!) works with any Macintosh. That’s right, even those lonely ones in
the corner with 64K ROMS.
Before we get to the code though, we’d like to cover some user interface
considerations, the proper use of menu and window definitions, some guidelines for
using our special MDEF, and a general explanation of how the whole thing works.
User-Interface Thought Police on Patrol
We’re going to pretend we’re Apple Computer and tell you how tear-off menus
and floating palettes should behave. After all, we are writing this with plural
pronouns.
Before a menu is torn off it must act like a normal menu. The currently selected
item must be highlighted when the menu is drawn. The current item must be
unhighlighted and another item must be highlighted as the mouse is tracked through the
menu. When the mouse button is released within the menu, the highlighted item must
flash and become the currently selected item.
When the mouse is more than 15 pixels outside the menu, a gray outline of the
palette must track the mouse until the button is released or the mouse moves back
within the menu or menu bar. The mouse must be ‘stuck’ to the top center of the gray
outline, just as if it were dragging a window by its title bar. If the mouse button is
released outside the 15 pixel boundary, a floating palette must appear within the gray
outline. See Figure 1.
If a non-application window is the front window when the menu is torn off, the
top-most document and any other floating palettes must be brought in front of that
non-application window. The torn-off menu must then become the top-most palette.
The top-most document or other floating palettes must never be unhighlighted when a
menu is torn off. See Figure 2.
Floating palettes must always remain above documents in their own layer and
they must have a user-selectable order in that layer. If the only visible document is
closed, all of the palettes must remain visible.
In a non-multitasking environment, whenever a non-application window is
brought to the front, the top-most document and all floating palettes must be
unhighlighted. See Figure 3. Under MultiFinder, whenever another application is
brought to the front, the top-most document must be unhighlighted and all of the
visible palettes must be hidden. When the application is brought back to the front, all
hidden palettes must be made visible and the top-most document must be highlighted.
Whew! And you thought Apple was stuffy in their “Human Interface Guidelines:
The Apple Desktop Interface,” a recent must-read publication from Addison-Wesley. If
you’ve got a copy handy, turn to pages 90 through 92 and see how close our definitions
match.
Hmmm. We seem to be much more specific about certain details. Why? Well,
after using HyperCard and the new MacPaint we began to notice some of the quirks we
mentioned earlier. Some behavior just didn’t seem to conform to the standard
Macintosh user interface. Like not unhighlighting floating palettes when a desk
accessory is brought to the front. Which then is active, the desk accessory or the
application? If the windows don’t overlap, the user can easily become confused.
Tear-off menus and floating palettes shouldn’t break any of the other normal
interface guidelines. Think of them as an extension or super-set of the regular Mac
interface. Also, always remember Scott Knaster’s rule, “Apple is not God.” That’s why
we don’t require the user to hold down the infamous command key to tear off a menu.
That rule reeks of modality. Why make the convenience of tearing off a menu with the
mouse more inconvenient by having to use the keyboard? Obviously Bill Atkinson feels
the same way. And remember, HyperCard is system software.
Of course, if you hold down the command key, our menus will still tear off.
And don’t be confused by Apple’s insistence that “if a single application can have
more than one menu torn off at a time, the application must determine their order of
precedence.” Of course, floating palettes must always be in some order. But the
application should let the user determine that order by clicking the mouse in the title
bars of the palettes. It’s still a determined order of precedence, just not fixed.
We did add one extension to our application’s user interface and it has nothing to
do with tear-off menus or floating palettes. It’s something that we think the Mac has
needed for quite awhile. In fact, Mike Schuster performed a similar extension with
Adobe Illustrator. This is simply to allow the user to send a window to the back by
holding down the option key and clicking on the window’s title bar. And we extended this
extension to include the palettes. A floating palette can be sent underneath all of the
other visible palettes in the same manner.
Also, just like the Finder, if the option key is held down while closing one of our
application windows, all open windows are closed.
Fig. 2 Our palette floats above the document window
Fig. 3 But it correctly allows DA windows on top!
Writing the Darn Thing
So now that we’ve decided what we want to do, how do we go about doing it?
Well, we could use Andy Hertzfield’s method but it’s very complex. Of course,
since Andy’s a genius you’d expect that. Andy decided to patch several Window Manager
traps and lie to the ROM about what’s actually going on in the Window Manager port. He
also plays hide-and-go-seek with the Menu Manager and a lot of other system
software. We decided not to get that low-level with our code since we’re only planning
to tear off a few of our application’s menus.