Hi,

Okay.  Glad to know there's a preference for that.  For the next
release, I'll make a proposal to upgrade this preference to a more
broad "pure objects mode" where the external world (e.g., filesystem)
can remain completely insulated away, and treat users to a pure
"object land" and, sure, there can be a designed portal for access to
the layers beneath Smalltalk like the filesystem,  os processes,
services, cron, etc.

Best,
  Chris



On Sun, Jan 23, 2022 at 1:58 AM Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>
> Hi Chris --
>
> > The above is how it used to work [...]
>
> I tweaked PluggableTextMorph >> #cancelSafely make it simple again and give model's the required control over #textEdited:, if they use it at all. Thanks for the clarification. We should watch out for simplicity and consistency here.
>
> > Currently, "cancel" in an Inspector bottom pane does nothing, which is kind of confusing, since the option is actually on the menu.
>
> Thanks. Fixed.
>
> > ... oh no! While testing this, I just noticed Workspaces now force you to save out to the external filesystem!
>
> Nobody is forced here. xD Just disable that preference in the preferences. It's also in the wizard. "Workspace fileOutOnAccept".
>
> Best,
> Marcel
>
> Am 23.01.2022 04:00:30 schrieb Chris Muller <asqueaker at gmail.com>:
>
> Hi Marcel,
>
> > I don't understand what you are talking about. Both "accept" and "cancel" have still consistent and predictable behaviors.
>
> Strictly from a user's perspective and not the responsibilities or
> implementation, when:
>
> 1) the user edits their useful contents
> 2) presses Accept --> System records the contents in a variable
> somewhere. State switches to non-dirty.
> 3) the user messes up their contents, state back to dirty.
> 4) user presses Cancel, contents reverts to last-accepted contents
> (from step 2).
>
> The above is how it used to work in Workspaces, and how it should work
> by default in _every_ text Model that doesn't override Accept and
> Cancel to do something else. It's a predictable and even quite useful
> behavior for workspaces for keeping scratch notes or long-term
> Inspectors or Explorers during long dev / debugging sessions involving
> a specific object.
>
> > The only "new thing", which was already there in 5.3, is maybe #textEdited: where models can directly intercept typed contents and use them.
>
> Currently, "cancel" in an Inspector bottom pane does nothing, which is
> kind of confusing, since the option is actually on the menu. But,
> you're right, Cancel only works in Workspaces in 5.3, not Inspectors
> or Explorers. But, it should! So, it's technically not a regression
> for this release. However...
>
> ... oh no! While testing this, I just noticed Workspaces now force
> you to save out to the external filesystem! I must've missed the
> discussion about this change. This is a *really negative* change to
> the IDE that goes far beyond "I work this way, you work that way." It
> establishes a new precedent that will (mis)lead new users to establish
> bad habits, IMO. I've tried to explain in past discussions how
> designing the seam between the image and the external world
> haphazardly is a mistake. Hopefully we'll consider an alternative to
> that. At a minimum, it should not be activated by "Accept" but a
> separate, explicit menu item (on the extras menu, not the primary) and
> with no hotkey. There are good IDE design reasons for doing this...
>
> Best,
> Chris
>