<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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'. </div><div><br></div><div>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. :) </div><div><br></div><div>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'.</div><div><br></div><div><br></div><div><br></div><div>On Aug 1, 2020, at 4:22 PM, Chris Muller wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>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.<br></div><div><br></div><div>But it should never close a multifield dialog, IMO. Maybe it shouldn't even for FillInTheBlank either, for consistency.</div><div><br></div><div> - Chris</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 1, 2020 at 7:28 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Chris,<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> schrieb am Fr., 31. Juli 2020, 22:47:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> *but*<br> <br> It would be a problem in dialogues with several input fields though; see for example the SqueakMap edit tool. </blockquote><div><br></div><div>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, ...</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Jakob</div><div class="gmail_quote" dir="auto"></div></div> </blockquote></div> <br></blockquote></div><br></div></body></html>