Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!agate!mica.berkeley.edu!mwm From: mwm@mica.berkeley.edu (Mike (I'll think of something yet) Meyer) Newsgroups: comp.windows.misc Subject: Pie menus Message-ID: <1989Oct28.053358.1517@agate.berkeley.edu> Date: 28 Oct 89 05:33:58 GMT Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44) Reply-To: mwm@mica.berkeley.edu (Mike (I'll think of something yet) Meyer) Organization: Missionaria Phonibalonica Lines: 38 >> > > That's an implementation detail, then. On the Amiga, for instance, the >> > > menus don't go through the layers system: the screen is frozen while the >> > > menu is up, but because it's so fast the screen isn't frozen for very long. >> >> > Dubious advantage. >> >> Well, it's a tradeoff. The biggest overhead in windowing seems to be managing >> the clipping lists rather than actually copying bits around. For something >> that's guaranteed to be short duration (unless you replace your mouse buttons >> with toggle switches :->) it's an OK tradeoff. It's not really an implementation detail. The win on pie menus is that you can make most any selection without being able to see the menu. I've as yet to run into any rectangular menu system (other than pie menus done in a rectangle) of which this was true. The result of this is that the menu selections wind up in the motion domain, not the menu domain. I make a selection without seeing any menus, because I know which way to go (up is paste; right click up opens a window on violet.berkeley.edu, etc). After the selection is made, rendering the menu just annoys me (by flashing it on and then deleting it), and doesn't really tell me anything that completing the action would. If a pie menu system renders menus even if the selection has been made, it's got a major misfeature, if not an outright bug. It sounds like Don may have changed things so that it does the rendering anyway. This is dissapointing.