geoff@pmafire.UUCP (Geoff Allen) (07/25/89)
There has been a bit of discussion lately over System 7.0. One of the
issues being discussed is tear-off menus. Apparently, they're going to
be supported in the new system (no more hacks). Several have said that
they thought that _all_ menus would be tear-off menus under System 7.0.
Here's some food for thought. (Is anyone at Apple listening??):
Let the user decide whether a given menu will be tear-off or not. For
example, when I'm working on a HyperCard stack, I almost always tear off
the "Tools" menu, because I often toggle between the browse, button, and
field tools. I think that with most programs there is one menu that is
accessed more often than others, and which menu that is might be
different from user to user. So let the user decide what tears and what
doesn't tear. Wouldn't it be nice to be able to tear off your "pet" menu,
but leave the others non-tear-off-able [for lake of a better word :-)].
This would prevent accidentally tearing off a menu you don't really want
hanging out in the air.
I don't know how practical this would be to try to implement, but I
think it's worth thinking about. What does everyone else think?
--
Geoff Allen - WINCO Systems Engineering | Disclaimer: WINCO doesn't believe
...{uunet|bigtex}!pmafire!geoff | in Macs, so of course these are
...ucdavis!egg-id!pmafire!geoff | only my own views.louis@asterix.drev.dnd.ca (Louis Demers) (07/27/89)
In article <694@pmafire.UUCP>, geoff@pmafire.UUCP (Geoff Allen) writes: > There has been a bit of discussion lately over System 7.0. One of the > issues being discussed is tear-off menus. Apparently, they're going to > be supported in the new system (no more hacks). > > Here's some food for thought. (Is anyone at Apple listening??): > > Let the user decide whether a given menu will be tear-off or not. > Wouldn't this also help prevent conflict with applications already implementing their own tear-off menus ? You could simply disable tear-offs for those menus already allowed to be torn-off by the applications. Speaking of hacks, almost every application has it's own floating palette/window code. Any chance Apple will set the record straight with System 7.0 and provide the programmers with such a facility ? ****************************************************************************** * Louis Demers * Defence Research Establishment Valcartier * * office = (418) 844-4424 * Electro-Optics Division * * lab = (418) 844-4265 * P.O. Box 8800 * * bed = (418) 839-9266 * 2459 PIE XI Blvd. * * louis@asterix.drev.dnd.ca * Courcelette, Quebec * * demers@ncs.dnd.ca * CANADA, G0A 1R0 * ******************************************************************************
PFTERRY@kuhub.cc.ukans.edu (08/01/89)
In article <694@pmafire.UUCP>, geoff@pmafire.UUCP (Geoff Allen) writes: > There has been a bit of discussion lately over System 7.0. One of the > issues being discussed is tear-off menus. Apparently, they're going to > be supported in the new system (no more hacks). Several have said that > they thought that _all_ menus would be tear-off menus under System 7.0. > > Let the user decide whether a given menu will be tear-off or not. For > example, when I'm working on a HyperCard stack, I almost always tear off > the "Tools" menu, because I often toggle between the browse, button, and > field tools. I think that with most programs there is one menu that is > accessed more often than others, and which menu that is might be > different from user to user. So let the user decide what tears and what > doesn't tear. Wouldn't it be nice to be able to tear off your "pet" menu, > but leave the others non-tear-off-able [for lake of a better word :-)]. > This would prevent accidentally tearing off a menu you don't really want > hanging out in the air. > > I don't know how practical this would be to try to implement, but I > think it's worth thinking about. What does everyone else think? A "somewhat" commercial INIT called TOM (Tear Off Menus) allows you to set a modifier key for tearing off a menu. For instance, you hold down the option key to tear off a menu. This may sound awkward, but it often kept me from ripping off a menu that I didn't want to. Also, TOM allows you to specify which programs it works in, and it automatically knows not to tear off "non-standard" menus (the palettes in HyperCard and PageMaker). Fred Terry KS Geological Survey Univ. of KS
hallett@mrsvr.UUCP (Jeff Hallett) (08/03/89)
Where does one come by this "somewhat commercial INIT" named TOM (tear-off menus)? Jeffrey Hallett, PET Systems Developer GE Medical Systems, Box 414 Milwaukee, WI 53201 (414) 548-5163
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (08/03/89)
In article <846@mrsvr.UUCP> hallett@mrsvr.UUCP (Jeff Hallett) writes: >Where does one come by this "somewhat commercial INIT" named TOM (tear-off menus)? Check the back pages of MacWeek. Meanwhile, I feel compelled to point out that their implementation of tear of menus is not quite as elegant as the Radius implementation (for example). The "tear off menu" is actually a window that has the menu items drawn in it. when you want to make selection from the menu, the code makes a call to popUpMenuSelect and pops up a menu in the window. It looks right, but the overhead involved in popping the menu causes a response lag and you must hold the mouse button down until the item you want is inverted. The Radius tear off menus are more like the Hypercard tear offs; you need only click on the item you want, not click and hold. I suggest that you get a copy of "heirDA" (in some versions it is called "DAMenuz"). It pops up a copy of the menu bar in popUpMenu format. It is (I think) distributed as freeware and is available by anonymous FTP from sumex-aim (36.44.0.6). ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
svc@well.UUCP (Leonard Rosenthol) (08/04/89)
In article <26944@srcsip.UUCP>, mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) writes: > In article <846@mrsvr.UUCP> hallett@mrsvr.UUCP (Jeff Hallett) writes: > > [discussion of the TOM Init and where to find it] > > Meanwhile, I feel compelled to point out that their implementation > of tear of menus is not quite as elegant as the Radius implementation > (for example). The "tear off menu" is actually a window that has the > menu items drawn in it. when you want to make selection from the menu, > the code makes a call to popUpMenuSelect and pops up a menu in the window. > It looks right, but the overhead involved in popping the menu causes a > response lag and you must hold the mouse button down until the item you > want is inverted. The Radius tear off menus are more like the Hypercard > tear offs; you need only click on the item you want, not click and hold. > Everything you have said above about the way that TOM implements TearOffs is competely true, as well as your comments about the Radius implementation...HOWEVER (you knew this was coming didn't you :-) the TOM method of doing tearoffs has some MAJOR advantages over the Radius method. My two biggest complaints about the Radius method are not true of the TOM method due to the way they implement tearoffs. First off, when you tear off a menu which is LARGER than your main monitor, the Radius implementation DOES NOT provide for scrolling and as such it becomes limiting in which menus you can tear off usefully. The other significant limitation of the Radius method has to do with hierMenus. If you tear off a main menu which as subMenus, you can NOT choose the subs off of the tearoff you have to either go back to the menuBar or tear off the subs separately. TOM on the other hand, by calling a standard/supported(!) Apple routine handles both of these issues properly and also insures that it will remain compatible (at least in that respect) in the future. It also means that you can tearOff any nonStandard MDEF which may due funky things since it ends up calling the MDEF to do all the processing itself rather than Radius ASSUMING what kind of processing you do... -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (08/08/89)
In article <13005@well.UUCP> svc@well.UUCP (Leonard Rosenthol) pointed out
some advantages of the TOM way of implementing tearoff menus vs. the Radius
way. The advantages were:
- TOM is able to handle menus longer than the screen height.
- TOM properly handles menus with heirarchical menus.
- Because of the way TOM works, it is more likely to be compatible with
non-standard MDEF menus.
My response:
These advantages are all very real. My point was that the developers could
have gone that extra mile and made TOM "feel" better. Clicking and holding
to make a menu selection from a tear off menu feels unnatural to me.
____________________________________________________________________
Have a day. :^|
Murat N. Konar Honeywell Systems & Research Center, Camden, MN
mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)gillies@m.cs.uiuc.edu (09/02/89)
Now I am really curious how tear-off menues will work in system 7.0. Will all menus be tear-off? Will this be a boolean option in every MENU resource? Will you have to hit a special key to tear off a menu? If no special key is necessary, won't it become harder to make menu selections (without inadvertently tearing away the menu)? What are the "right" semantics for pulling-down a menu, when the tear-off is already sitting on the desktop?