<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Marcel, all,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think I finally understand the logic behing Accept and Cancel… neat :) However, for a newcomer this is probably undiscoverable without help. I don’t get this though: if I accept my changes in a Workspace and close the workspace window
- how do I get the last accepted contents back? If I accept my changes in say a method and close the Browser I know my changes are still there. So similarly I’d expect to find my last accepted Workspace changes somewhere - and I don’t know where - is this
what I’m still missing? And quite logically then, if I crash my image (which is often) I’ll know my changes are lost unless explicitly filed out in advance. (changes file is not helpful in this case because it doesn’t store all Workspace content, just some,
if I’m not mistaken).</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best,</p>
<p class="MsoNormal">Jaromir</p>
<div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:marcel.taeumel@hpi.de">Marcel Taeumel</a><br>
<b>Sent: </b>Tuesday, January 25, 2022 12:15<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev</a><br>
<b>Subject: </b>Re: [squeak-dev] The Trunk: Morphic-mt.1852.mcz</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi all --<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Note that I am still pondering about the importance of those conflicting scenarios:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">(1) Disable #fileOutOnAccept. Use accept/cancel operations to manage per-window Workspace (model) contents. Enable "Make unclosable" in a window if close button is
too dangerous.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">(2) Enable #fileOutOnAccept. Treat workspaces as code editors. Rely on CMD+S to persist input just like, e.g., System Browser does. Rely on "Unsaved changes" notification
when trying to close a window with unsaved changes.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">***<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">I think that (1) is quite challenging to discover. (2) might be the more common expectation nowadays.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Best,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Marcel<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 8.0pt;margin-left:0in;margin-top:15.0pt;margin-bottom:5.0pt;min-width: 500px">
<p style="margin-top:7.5pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#AAAAAA">Am 25.01.2022 12:04:25 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi all --<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">There were very good points raised about this issue. While the old situation was far from perfect and arguably confusing for non-Veteran Smalltalkers, I agree that
the current situation is not perfect. Let's keep on moving forward. Given that the next release is not too far away, there may be changes that just make use of the possible instead of creating a really good solution.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Best,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Marcel<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 8.0pt;margin-left:0in;margin-top:15.0pt;margin-bottom:5.0pt;min-width: 500px">
<p style="margin-top:7.5pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#AAAAAA">Am 24.01.2022 23:57:15 schrieb Jaromir Matas <mail@jaromir.net>:<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">> Accept has nothing to do with "persisted and saved".<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">I’m quite new to the Smalltalk environment but I guess once “Accept” is associated with CTRL+s (or Cmd+s)
it inevitably brings some expectations (for newcomers at least); it may not have been like that some time ago but I’d say for many people CTRL+s is simply expected to "save". I’m not saying it’s good or bad and I don’t know how to solve it… just saying :)<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Best,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Jaromir<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">From:
</span></b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:ma.chris.m@gmail.com">Chris Muller</a><br>
<b>Sent: </b>Monday, January 24, 2022 23:17<br>
<b>To: </b><a href="mailto:marcel.taeumel@hpi.de">Marcel Taeumel</a><br>
<b>Cc: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev</a><br>
<b>Subject: </b>Re: [squeak-dev] The Trunk: Morphic-mt.1852.mcz<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi Marcel,<br>
<br>
> I like your ideas. Yet, let's not forget the main aspect of this feature here. The "accept" operation in workspaces has been misleading for many years. Users relied on contents being persisted and save. This was not true. ;-)<br>
<br>
When you "Accept" the contents of an Inspector's selected variable, it<br>
updates the variable, it doesn't save anything to disk. Accept has<br>
nothing to do with "persisted and saved". It simply means the user<br>
wants to "accept" (in the most abstract sense) the contents, whereas<br>
Cancel means cancel and revert to the last-accepted state. Even<br>
"persist" does not necessarily mean "save to disk", but simply,<br>
"persist", past something. In your example it's persist past image<br>
restarts (by saving to disk), but could just as easily refer to<br>
"persisting" past the next Cancel...<br>
<br>
> Maybe we can show a simple information when the user tries to accept the contents but they are actually not persisted at all. Hmm...<br>
<br>
Why would you want a dead-end UI function that argues with the user<br>
and sinks their time instead of just removing "Accept" entirely from<br>
the menu in the first place? Pop ups should only be a last resort,<br>
never a first one. Modal pop ups are a crutch indicative of a bad<br>
design in general. Please, no more pop ups!<br>
<br>
IMO, it's more useful and much clearer for the user if "Accept" does<br>
*something*, rather than nothing.<br>
<br>
> > broad "pure objects mode"<br>
><br>
> This could work on top of existing preferences. I would never want to see a check for #isPureObjectMode in the source code. Such checks must for more specific in order to keep the system maintainable. Similar to #isNoviceMode or even #isLinux ... those are
very dangerous totally ambiguous.<br>
<br>
Hmm, without getting into an argument about those examples, let me<br>
assure you that my notion of "pure objects mode" is very specific.<br>
It's whether Squeak should present a walled-garden of objects, or a<br>
general-purpose computer utility. In the latter, the underlying<br>
computer is an Actor in the use cases, in the former, it isn't.<br>
Concrete and simple. But I wasn't considering a #isPureObjectMode<br>
switch as the implementation anyway, but delegating to a<br>
SqueakIdeStrategy (not necessarily the final name or implicit scope)<br>
strategy with one subclass that does the pop up FileSelector thing,<br>
and a different subclass that handles it quietly and seamlessly. What<br>
we've got at the moment is an IDE that is 98% seamless except for the<br>
one or two new "holes" that we poked into it from places in the IDE<br>
that seemed like a "convenient" way to scratch a particular itch.<br>
Unfortunately, it spoiled our ability to present a walled-garden, and<br>
even in an insidious way that is "good enough" to manage one's<br>
Preference file that will deter users from developing the better way,<br>
via build scripting.<br>
<br>
Best,<br>
Chris<o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:1.0in;mso-margin-bottom-alt:auto">
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>