[squeak-dev] The Trunk: Morphic-mt.1852.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Tue Jan 25 11:04:25 UTC 2022

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.

Am 24.01.2022 23:57:15 schrieb Jaromir Matas <mail at jaromir.net>:
> 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 :)
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.

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

More information about the Squeak-dev mailing list