> On 2020-07-31, at 8:24 AM, Tim Johnson <digit@sonic.net> wrote:
>
> If Cmd-s is a shortcut for "accept" (which I think it is, throughout most of Squeak), and in this dialog, "accept" (i.e. the "accept" button) saves the image with the new name and closes the dialog, then Cmd-s should perform the "accept" operation, which closes the dialog.
>
> I don't mean to defend this metaphor, but it seems consistent throughout most of Squeak...
I'm pretty much in agreement here; we use cmd-s all over the place as 'save/finish/accept' and it makes sense (to me) for a lot of dialogues.
Me too. +1
*but*
It would be a problem in dialogues with several input fields though; see for example the SqueakMap edit tool.
That's different. Not modal. Just like the code browser, where you don't want Cmd+s to close the code browser. But for modal dialogs, yes, and, before FileDialog, "save image as..." did, via the standard FillInTheBlank. I miss it terribly, and remain strongly against even the concept of presenting a FileDialog to the user for "save image as..." as well as for saving and loading preferences. It's appropriate for adding Monticello DirectoryRepositories, because that's what that use-case is about but, IMO, it's actually harmful in those other ones.
It could be a problem for dialogues where we allow longer text that might have CRs.
Actually, that's where Cmd+s is useful isn't it? So that Return can insert the CR's instead of accepting the dialog..?
We do need to keep it possible to close/accept/cancel with just keyboard input as well.
+1
Possibly it would also help to make the text field in such dialogues *not* have the stuff-changed-triangle; that might be a cue that you don't use cmd-s in it?
-1
Best,
Chris