<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi all --<div><br></div><div>Note that I am still pondering about the importance of those conflicting scenarios:</div><div><br></div><div>(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.</div><div><br></div><div>(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.</div><div><br></div><div>***</div><div><br></div><div>I think that (1) is quite challenging to discover. (2) might be the more common expectation nowadays.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 25.01.2022 12:04:25 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi all --<div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 24.01.2022 23:57:15 schrieb Jaromir Matas <mail@jaromir.net>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div class="WordSection1">
<p class="MsoNormal">Hi,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> Accept has nothing to do with "persisted and saved".<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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 :)</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best,</p>
<p class="MsoNormal">Jaromir<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></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: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</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div></blockquote></div></div></blockquote></div>