Hi Tim and tim,   :)

> On 2020-07-31, at 8:24 AM, Tim Johnson <digit at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/d0f2f2b9/attachment.html>