Smalltalk › Squeak › Squeak - Dev

5.3, focus follows mouse, image "save as..."

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Tim Johnson-2

5.3, focus follows mouse, image "save as..."

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

marcel.taeumel

Re: 5.3, focus follows mouse, image "save as..."

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 <[hidden email]>:
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? :)

marcel.taeumel

Re: 5.3, focus follows mouse, image "save as..."

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 <[hidden email]>:
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 <[hidden email]>:
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? :)

Jakob Reschke

Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

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
<[hidden email]>:

>
> 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 <[hidden email]>:
>
> 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 <[hidden email]>:
>
> 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? :)
>
>
>
>

Jakob Reschke

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

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
<[hidden email]>:

>
> 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
> <[hidden email]>:
> >
> > 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 <[hidden email]>:
> >
> > 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 <[hidden email]>:
> >
> > 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? :)
> >
> >
> >
> >

Tim Johnson-2

Re: 5.3, focus follows mouse, image "save as..."

In reply to this post by marcel.taeumel

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

Tim Johnson-2

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

In reply to this post by Jakob Reschke

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
> <[hidden email]>:
>>
>> 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
>> <[hidden email]>:
>>>
>>> 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
>>> <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>
>>> 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? :)
>>>
>>>
>>>
>>>
>
>

Picture 29.png (12K) Download Attachment

Tim Johnson-2

Re: 5.3, focus follows mouse, image "save as..."

In reply to this post by Tim Johnson-2

On Jul 31, 2020, at 8:20 AM, Tim Johnson wrote:

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.

Yes, upon further contemplation, and with the input that it doesn't happen on other platforms, I think I must have been running into the "modifier keys get stuck when Cmd-Tab is hit to switch away from Squeak on OS X" issue. So, while I thought I was hitting "return", the image actually thought I was hitting opt-return, or cmd-return, or shift-return, etc. This issue was so prevalent on macOS / OS X that I actually got into the habit of hitting shift - ctrl - option - cmd in rapid succession whenever switching back to Squeak using Cmd-Tab. But I've forgotten about the issue lately because I've been using other environments.

This issue is also why I wrote ModifierKeysMorph: https://github.com/tcj/ModifierKeysMorph :)

Thanks, and sorry for the noise.

Tim

timrowledge

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

In reply to this post by Tim Johnson-2

> On 2020-07-31, at 8:24 AM, Tim Johnson <[hidden email]> 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. *but*

It would be a problem in dialogues with several input fields though; see for example the SqueakMap edit tool. It could be a problem for dialogues where we allow longer text that might have CRs. We do need to keep it possible to close/accept/cancel with just keyboard input as well.

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?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- She doesn't suffer from insanity; she enjoys every minute of it.

Chris Muller-3

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

Hi Tim and tim, :)

> On 2020-07-31, at 8:24 AM, Tim Johnson <[hidden email]> 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.

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

timrowledge

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

> On 2020-07-31, at 1:46 PM, Chris Muller <[hidden email]> wrote:
>
> But for modal dialogs, yes, and, before FileDialog, "save image as..." did, via the standard FillInTheBlank.

<return> works to accept anything you type in the filename field. cmd-S not working is purely down to whatever key filtering wotsit got added and I accept no responsibility for that.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A hacker does for love what others would not do for money.

Jakob Reschke

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

In reply to this post by Chris Muller-3

Hi Chris,

Chris Muller <[hidden email]> 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

Jakob Reschke

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

In reply to this post by timrowledge

Hi Tim,

tim Rowledge <[hidden email]> schrieb am Fr., 31. Juli 2020, 19:57:

It would be a problem in dialogues with several input fields though; see for example the SqueakMap edit tool. It could be a problem for dialogues where we allow longer text that might have CRs. We do need to keep it possible to close/accept/cancel with just keyboard input as well.

A related topic might be the absence of tab navigation in Squeak. In many GUI systems there is a key to move the focus to the next widget, mostly the tab key. There is no such thing in Squeak, is it?

Kind regards,

Jakob

Chris Muller-4

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

In reply to this post by Jakob Reschke

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 <[hidden email]> wrote:

Hi Chris,

Chris Muller <[hidden email]> 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

Tim Johnson-2

Re: Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...")

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 <[hidden email]> wrote:
Hi Chris,

Chris Muller <[hidden email]> 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