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

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