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...

FillInTheBlank request: 'how are you?'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 29.png
Type: image/png
Size: 9201 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200731/a2db9a2d/attachment.png>
-------------- next part --------------



^^ see the "(s)" in Accept.



On Jul 31, 2020, at 7:05 AM, Jakob Reschke wrote:

> My own answer:
>
> I find it highly unusual and never expect to close something with
> Cmd-s. Outside of Squeak I know about pressing Enter/Return on a main
> text entry, or even the space bar if it is a button, to close a
> dialog. But not "save = close".
>
> But it seems like this used to (or should?) work to save an image, and
> I also got a ticket in Squot to add this behavior to the commit
> dialog.
>
> That's why I would like to know how much of a Squeak interaction idiom
> this really is, where does it come from, and what other systems
> exhibit this behavior?
>
> Am Fr., 31. Juli 2020 um 16:03 Uhr schrieb Jakob Reschke
> <forums.jakob at resfarm.de>:
>>
>> Hi all,
>>
>> Under which circumstances do you expect that the "accept" action and
>> more specifically pressing Cmd-s _close_ a dialog window or whatever
>> thing you have been entering text in?
>>
>> Kind regards,
>> Jakob
>>
>>
>>
>> Am Fr., 31. Juli 2020 um 10:13 Uhr schrieb Marcel Taeumel
>> <marcel.taeumel at hpi.de>:
>>>
>>> And: Looking at the current implementation of FileSaverDialog,  
>>> that "unaccepted changes"-triangle is used to let the user type in  
>>> a file name and only after [cmd+s] check whether that name has the  
>>> required suffix. [return] or [enter] both combine that behavior  
>>> with a final accept-and-close in the dialog.
>>>
>>> So, [cmd+s] is not intended to close the dialog. Just type in and  
>>> hit [enter] or [return]. That is implemented via an event filter  
>>> and works fine in Squeak 5.3 on Windows 10, too.
>>>
>>> Yes, it would be possible the change the implementation to let [cmd 
>>> +s] also close the dialog.
>>>
>>> No, it is actually unrelated to the preference "mouse over for  
>>> keyboard focus". Something else is going on in your image or  
>>> platform. :-)
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 31.07.2020 09:55:27 schrieb Marcel Taeumel  
>>> <marcel.taeumel at hpi.de>:
>>>
>>> Hi Tim,
>>>
>>> Windows 10 here. Works for me in recent Trunk (Build 19801) with  
>>> [return]. Does not work with [cmd+s]. "Mouse over for keyboard  
>>> focus" enabled, of course. ;-)
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 31.07.2020 06:31:07 schrieb Tim Johnson <digit at sonic.net>:
>>>
>>> Hi all,
>>>
>>> In 5.3, when using the World menu, "Save as...," on macOS / OS X,  
>>> with focus-follows-mouse[1] turned on, I enter my new file name,  
>>> and when I press return or Cmd-S, the dialog does not go away.  
>>> (Even if I leave the mouse focus in that input field.) My "changes  
>>> are accepted," so to speak (the orange triangle goes away), but  
>>> the image is not saved and the dialog does not go away. It seems  
>>> like I still have to go click "accept".
>>>
>>> I think in every previous version of Squeak I've used, in the  
>>> dialog that appears upon choosing World menu -> "save as...", I  
>>> can just type the new name and hit return or Cmd-S and the dialog  
>>> will go away and the image will be saved.
>>>
>>> With focus-follows-mouse turned off, 5.3 works as intended: enter/ 
>>> return dismisses the dialog and the image is saved with the new  
>>> name.
>>>
>>> Wondering if this can be categorized as a regression[2]. To  
>>> verify, I just tested in 5.2. Indeed, in 5.2, whether focus- 
>>> follows-mouse is turned on or off, I can enter a new file name and  
>>> press enter/return and the image will be saved under the new name.  
>>> I don't have to move my mouse to click the "accept" button.
>>>
>>> Could this somehow related to any other issues with where keyboard  
>>> focus and/or events are going? (Specifically talking about how  
>>> entire windows are refreshing with every keypress into a code  
>>> pane, for example.)
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> [1] Preferences valueOfFlag: #mouseOverForKeyboardFocus
>>>
>>> [2] regression meaning: since I care, I have to fix it? :) Or,  
>>> regression meaning: I file a bug in Mantis? :)
>>>
>>>
>>>
>>>
>
>