[squeak-dev] The Trunk: Morphic-mt.1852.mcz
ma.chris.m at gmail.com
Mon Jan 24 22:17:06 UTC 2022
> 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.
More information about the Squeak-dev