b_murphy@fennel.cc.uwa.oz.au (10/12/90)
Keywords: Human Interface Guidelines, Modal Dialog Box, Command Key
Summary: What is your opinion about the handeling of Command Key
equivalences within Modal Dialog Boxes?
From: B_MURPHY@VAXA.UWA.OZ.AU (Onno)
I would like to know your opinion on the following:
If a modal dialog is on the screen, what do you do with CUT/COPY/PASTE? I
have seen many implementations where the menu doesn't work, but the command
keys do. Also I've seen help-screens appear while a modal dialog was up.
I find from own experiance that I tend not to try to hit outside the box
because it's a modal box that requres you to do something first. *BUT*
(There's *always* a but!:-) in for instance MPW, using the command keys
you can paste a <CR> into the Search/Replace box where as you cannot hit
<CR> (It'll go and Find.) The HIGs says something across the lines that
the keyboard-equivalences are just that, equivalences, something you can
also do by selecting from the menu.
Idea: Grey the whole menu bar *execpt* 'EDIT' and maybe the help item
where ever it is.
OR: Do not allow CUT/COPY/PASTE and supply the user with <CR> and <TAB>
equivalences.
OR: (This is really snazzy ;-) Supply the user with either buttons
in the dialog that do CUT/COPY/PASTE, or a menu in the dialog.
What do *you* think?
While I'm at it, is there anyone *outside* Australia actually *READING*
this, 'cuz I got the distinct impression we were on our lonesome here.
(PinkFloyd: Is there anybody out there? :-)
-o (short for On-no)
()/)/)() can be r e a c h e d at B_MURPHY@VAXA.UWA.OZ.AU
_____________________________________________________________________
The net never sleeps, come to think of it, do I ever?
----> Thinking is dangerous, subversive and leads you astray. <----
P.S. That LC looked *REALLY* sleek, and I *LOVED* the mike-tie clip
good job Apple...mystone@mondo.engin.umich.edu (Dean Yu) (10/15/90)
In article <1990Oct12.114610.2427@fennel.cc.uwa.oz.au> b_murphy@fennel.cc.uwa.oz.au writes: >Idea: Grey the whole menu bar *execpt* 'EDIT' and maybe the help item > where ever it is. This is taken care of in System 7. The menu bar is disabled except for the Edit and Help menus, both of which work. The Edit menu items will even work automagically in current applications when you run them under System 7. >OR: (This is really snazzy ;-) Supply the user with either buttons > in the dialog that do CUT/COPY/PASTE, or a menu in the dialog. > Personally, I'm not too hot on menus in windows. I find myself shooting past the menu bar all the time in applications that have this feature. I like to be able to just toss me mouse up, and have the cursor stop at the top of the screen. Of course, it could be because I've got cocaine mouse... >While I'm at it, is there anyone *outside* Australia actually *READING* >this, 'cuz I got the distinct impression we were on our lonesome here. >(PinkFloyd: Is there anybody out there? :-) No, no one's actually reading this. It's all a figment of your imagination. :) -- Dean _______________________________________________________________________________ Dean Yu | E-mail: mystone@mondo.engin.umich.edu Patches 'R' Us | Real-mail: Dean Yu A Division of Cyberite Systems | 909 Church St Apt C | Ann Arbor, MI 48104 I'm not the voice of Reason, much | Phone: 313 662-4073 less the voice of Cyberite. | 313 662-4163 -------------------------------------------------------------------------------
francis@daisy.uchicago.edu (Francis Stracke) (10/15/90)
In article <1990Oct12.114610.2427@fennel.cc.uwa.oz.au> b_murphy@fennel.cc.uwa.oz.au writes: >If a modal dialog is on the screen, what do you do with CUT/COPY/PASTE? I >have seen many implementations where the menu doesn't work, but the command >keys do. Also I've seen help-screens appear while a modal dialog was up. It seems to be a bit difficult to get the command keys to work in a modal dialog; you need a filterproc, of course, but I haven't been able to make that work, either. (To be fair, I haven't tried very hard--but the filter never saw those command-keys.) >Idea: Grey the whole menu bar *execpt* 'EDIT' and maybe the help item > where ever it is. Seems a bit involved. Seeing a modal should be clear enough. Besides, then you'd have to get the system to let the user click on the edit menu, even with the modal up. >OR: Do not allow CUT/COPY/PASTE and supply the user with <CR> and <TAB> > equivalences. These are not the only uses for cutting/etc. >OR: (This is really snazzy ;-) Supply the user with either buttons > in the dialog that do CUT/COPY/PASTE, or a menu in the dialog. This is NOT snazzy. Snazzy is doing it the same way people are used to outside the dialog--i.e., with command-keys. Making me drag the mouse around to do such a simple operation (especially one for which I ALWAYS use command-keys) is not friendly. >While I'm at it, is there anyone *outside* Australia actually *READING* >this, 'cuz I got the distinct impression we were on our lonesome here. We're here; you may not see us, because most newsposters default the distribution area to "usa" (most here, anyway). I set the distribution on this one to "world"--hope that does it. | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | A mathematician is a professional | | francis@zaphod.uchicago.edu | schizophrenic.--Me. |
amanda@visix.com (Amanda Walker) (10/16/90)
In article <1990Oct12.114610.2427@fennel.cc.uwa.oz.au> b_murphy@fennel.cc.uwa.oz.au writes: >What do *you* think? Don't use modal dialogs. I'm fairly serious--most modal dialogs could be replaced with modeless ones. For those very few that can't, interpreting the command keys and the Edit menu is a reasonable compromise. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- When you are not looking at it, this posting is in French.
leonardr@svc.portal.com (Leonard Rosenthol) (10/16/90)
In article <1990Oct15.060454.25957@engin.umich.edu>, mystone@mondo.engin.umich.edu (Dean Yu) writes: > In article <1990Oct12.114610.2427@fennel.cc.uwa.oz.au> b_murphy@fennel.cc.uwa.oz.au writes: > >Idea: Grey the whole menu bar *execpt* 'EDIT' and maybe the help item > > where ever it is. > > This is taken care of in System 7. The menu bar is disabled except for the > Edit and Help menus, both of which work. The Edit menu items will even work > automagically in current applications when you run them under System 7. > Are you saying that in 7.0, when I call Modal Dialog, all of my menus are automagically disabled EXCEPT for Edit and Help?? This raises a couple of interesting questions: 1) What happens if my Edit menu is localized into another script? 2) What if I specifically disable all my menus before calling ModalDialog, will the System now reset my disabling for me?!?! 3) Are ALL of the standard Edit commands supported, including Undo?? 4) What about cmdKey equivs for apps that don't have them, or have them remapped? Is MenuKey called? Also, what about F1-F4?? 5) Are you also setting the IBeam over edit fields?? If this is done correctly, great! I've implemented all of this stuff in my applications for a long time, and it is great to see Apple finally catching up to the rest of us ;-) -- Leonard Rosenthol Software Ventures Corp. MicroPhone II Development Team
mystone@mondo.engin.umich.edu (Dean Yu) (10/16/90)
In article <1990Oct15.191402.8463@svc.portal.com> leonardr@svc.portal.com (Leonard Rosenthol) writes: > Are you saying that in 7.0, when I call Modal Dialog, all of my menus >are automagically disabled EXCEPT for Edit and Help?? This raises a couple >of interesting questions: Yeah. >1) What happens if my Edit menu is localized into another script? Dunno... >2) What if I specifically disable all my menus before calling ModalDialog, >will the System now reset my disabling for me?!?! Let's see if I got this straight... You're asking that if you disabled your menu, and the system enables the Edit menu to support TextEdit fields, will it disable them again upon leaving ModalDialog, right? Yes, this is true. >3) Are ALL of the standard Edit commands supported, including Undo?? Alas, just Cut, Copy, and Paste. >4) What about cmdKey equivs for apps that don't have them, or have them > remapped? Is MenuKey called? Also, what about F1-F4?? I haven't seen an application that doesn't have command key equivalents in a long time, so I don't know what happens in this case. >5) Are you also setting the IBeam over edit fields?? IBeam is being set for edit fields. But not by me. _______________________________________________________________________________ Dean Yu | E-mail: mystone@mondo.engin.umich.edu Patches 'R' Us | Real-mail: Dean Yu A Division of Cyberite Systems | 909 Church St Apt C | Ann Arbor, MI 48104 I'm not the voice of Reason, much | Phone: 313 662-4073 less the voice of Cyberite. | 313 662-4163 -------------------------------------------------------------------------------
roland@dna.lth.se (Roland Mansson) (10/16/90)
In article <1990Oct15.191402.8463@svc.portal.com> leonardr@svc.portal.com (Leonard Rosenthol) writes: >3) Are ALL of the standard Edit commands supported, including Undo?? >4) What about cmdKey equivs for apps that don't have them, or have them > remapped? Is MenuKey called? Also, what about F1-F4?? >5) Are you also setting the IBeam over edit fields?? > > If this is done correctly, great! I've implemented all of this stuff >in my applications for a long time, and it is great to see Apple finally >catching up to the rest of us ;-) I've written a cdev that takes care of 3) (except Undo), 4) (no remapping), and 5). It also lets you select (most) buttons from the keyboard. I've sent it to sumex and comp.binaries.mac, and it is currently available from pollux.lu.se (130.235.132.89) in pub/mac/cdev as DialogFilter.hqx. -- Roland Mansson, Lund University Computing Center, Box 783, S220 07 Lund, Sweden Phone: +46-46107436 Fax: +46-46138225 Bitnet: roland_m@seldc52 Internet: roland.mansson@ldc.lu.se or roland.mansson%ldc.lu.se@uunet.uu.net UUCP: {uunet,mcvax}!sunic!ldc.lu.se!roland.mansson AppleLink: SW0022