bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/06/87)
In article <4490@sunybcs.UUCP> jmpiazza@gort.UUCP (Joseph M. Piazza) writes: <In article <447@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: <> <>Instead of using double-clicks (and ignoring shift-doubleclicks), how <>about using some previously undefined sequence like alt-click or ctrl-shift <>that doesn't conflict with existing programs.... <> <[Use] Right double-click. Delegating the right button to menus only seems <so wasteful. And it's one-handed. Though it is hardly ever used, a double-click on the right (menu) button is already assigned. It can bring up a Double Menu Requester, under the pointer. I do, however, agree with the need for one-handedness. I chose double-click for ClickToFront because it extended the already established meaning of the sequence. From the Workbench to double-click something is to "open up" or "emhasize". Double-clicking a disk or drawer icon already does a WindowToFront() on the referenced object. The only program I have found that ClickToFront hates is "Blitz". The way that program was set up causes the invisible, full screen window to be brought *forward*, in front of the title bar. (Just click the right button to restore things). It's obvious that this could be fixed easily. (While he is at it, the author of Blitz could fix the crashing file requester and eliminate the busy-wait :-).