[squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")
digit at sonic.net
Fri Jul 31 15:24:03 UTC 2020
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
Size: 9201 bytes
Desc: not available
-------------- 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
> 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,
>> 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. :-)
>>> 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. ;-)
>>> 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 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
>>> Wondering if this can be categorized as a regression. 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.)
>>>  Preferences valueOfFlag: #mouseOverForKeyboardFocus
>>>  regression meaning: since I care, I have to fix it? :) Or,
>>> regression meaning: I file a bug in Mantis? :)
More information about the Squeak-dev