Hi Marcel, all,

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).

Best,
Jaromir
From: Marcel Taeumel<mailto:marcel.taeumel at hpi.de>
Sent: Tuesday, January 25, 2022 12:15
To: squeak-dev<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] The Trunk: Morphic-mt.1852.mcz

Hi all --

Note that I am still pondering about the importance of those conflicting scenarios:

(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.

(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.

***

I think that (1) is quite challenging to discover. (2) might be the more common expectation nowadays.

Best,
Marcel

Am 25.01.2022 12:04:25 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi all --

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.

Best,
Marcel

Am 24.01.2022 23:57:15 schrieb Jaromir Matas <mail at jaromir.net>:
Hi,

> Accept has nothing to do with "persisted and saved".

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

Best,
Jaromir


From: Chris Muller<mailto:ma.chris.m at gmail.com>
Sent: Monday, January 24, 2022 23:17
To: Marcel Taeumel<mailto:marcel.taeumel at hpi.de>
Cc: squeak-dev<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] The Trunk: Morphic-mt.1852.mcz

Hi Marcel,

> 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. ;-)

When you "Accept" the contents of an Inspector's selected variable, it
updates the variable, it doesn't save anything to disk.  Accept has
nothing to do with "persisted and saved".  It simply means the user
wants to "accept" (in the most abstract sense) the contents, whereas
Cancel means cancel and revert to the last-accepted state.  Even
"persist" does not necessarily mean "save to disk", but simply,
"persist", past something.  In your example it's persist past image
restarts (by saving to disk), but could just as easily refer to
"persisting" past the next Cancel...

> Maybe we can show a simple information when the user tries to accept the contents but they are actually not persisted at all. Hmm...

Why would you want a dead-end UI function that argues with the user
and sinks their time instead of just removing "Accept" entirely from
the menu in the first place?  Pop ups should only be a last resort,
never a first one.  Modal pop ups are a crutch indicative of a bad
design in general.  Please, no more pop ups!

IMO, it's more useful and much clearer for the user if "Accept" does
*something*, rather than nothing.

> > broad "pure objects mode"
>
> 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.

Hmm, without getting into an argument about those examples, let me
assure you that my notion of "pure objects mode" is very specific.
It's whether Squeak should present a walled-garden of objects, or a
general-purpose computer utility.  In the latter, the underlying
computer is an Actor in the use cases, in the former, it isn't.
Concrete and simple.  But I wasn't considering a #isPureObjectMode
switch as the implementation anyway, but delegating to a
SqueakIdeStrategy (not necessarily the final name or implicit scope)
strategy with one subclass that does the pop up FileSelector thing,
and a different subclass that handles it quietly and seamlessly.  What
we've got at the moment is an IDE that is 98% seamless except for the
one or two new "holes" that we poked into it from places in the IDE
that seemed like a "convenient" way to scratch a particular itch.
Unfortunately, it spoiled our ability to present a walled-garden, and
even in an insidious way that is "good enough" to manage one's
Preference file that will deter users from developing the better way,
via build scripting.

Best,
  Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220125/740c2e1a/attachment.html>