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@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@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@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? :)

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?'

^^ 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@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@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@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@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? :)

Hi Tim and tim, :)

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

Hi Chris,

Chris Muller asqueaker@gmail.com schrieb am Fr., 31. Juli 2020, 22:47:

...

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

What do you think about windows that are input requesting dialogs, but not modal, as in: prevents other interactions while it is open? The commit dialog of the Git Browser falls into this category. But even though the Monticello save dialog will claim to be modal if its process is interrupted, it isn't really since you can do other things while it is open. So you could also answer with the Monticello save window in mind. Or the Monticello merge tool, which does not have text input for a change.

Kind regards, Jakob

The Orange Book specifically lists 'accept' in the Menu Command Index, page 510 in my edition. It separates out its instances in the book by 'to compile' and 'to store'. The second paragraph on page 37 describes what happens if a user tries to dismiss a dialog with changes, without the user clicking 'accept' or 'cancel'.

I realize this is all MVC and ancient history by now (?), but I first started learning & understanding Squeak by using the Orange Book & Blue Book in Squeak's early MVC and Morphic environments. Squeak hadn't diverged much, in MVC or in Morphic, by 3.8/3.9/3.10 or so. Nowadays, I'm not sure how helpful it is that I am mentioning a 36- year-old book. :)

The definition of 'undo' on page 58 is also interesting: it seems like it was never meant to replace 'accept'/'cancel', but was meant to exist beside these and remain a tool of its own. Thus the MVC environment could be said to have given the user two levels of 'undo'.

On Aug 1, 2020, at 4:22 PM, Chris Muller wrote:

It used to be that Cmd+s would remember the contents of text fields in windows, so that if I then made further modifications to it which I *then* change my mind about, I could press Cmd+l (lowercase L), to restore it to the last-accepted state. I really miss that in Workspaces and inspectors.

But it should never close a multifield dialog, IMO. Maybe it shouldn't even for FillInTheBlank either, for consistency.

• Chris

On Sat, Aug 1, 2020 at 7:28 AM Jakob Reschke forums.jakob@resfarm.de wrote: Hi Chris,

Chris Muller asqueaker@gmail.com schrieb am Fr., 31. Juli 2020, 22:47:

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

What do you think about windows that are input requesting dialogs, but not modal, as in: prevents other interactions while it is open? The commit dialog of the Git Browser falls into this category. But even though the Monticello save dialog will claim to be modal if its process is interrupted, it isn't really since you can do other things while it is open. So you could also answer with the Monticello save window in mind. Or the Monticello merge tool, which does not have text input for a change.

Kind regards, Jakob

On Jul 31, 2020, at 1:12 AM, Marcel Taeumel wrote:

No, it is actually unrelated to the preference "mouse over for keyboard focus". Something else is going on in your image or platform. :-)

OK, thanks. I guess I should have tried more permutations of VM and image and keyboards before posting.

"But it works in 5.2..." Hmm.

Tim