>>(an example I'll propose: "Whenever an
>>>answer dialog is to be displayed as the result of a user action, the dialog
>>>is skipped and the default answer is returned if the optionKey is down.")
>
> I don't like this. The option key is for other things, and hitting return
>will usually be fast enough. Also, imagine you have a script triggered by
>an option-click and it brings up a dialog. You'd never even see it. It'd
>interfere too much with what users are doing.
Uli, et al:
We can debate this further when we get to the point of establishing
programming conventions. My initial reaction is "the option key is for
whatever we decide it to be for."
If you don't like the key choice (and BTW this is exactly what the Finder
uses option key for when you select Empty Trash), how about the concept?
How many times have you cursed at an app "Of course I want to delete the
..., that's why I selected 'Delete'."? Wouldn't you like a way for someone
who knows the app to bypass those kinds of dialogs? I would.
Rob Cozens, CCW
http://www.serendipitysoftware.com/who.html
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
