<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">

                                        Hi Chris --<div><br></div><div>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. ;-) </div><div><br></div><div>Maybe we can show a simple information when the user tries to accept the contents but they are actually not persisted at all. Hmm...</div><div><br></div><div><span style="font-size: 10pt">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">broad "pure objects mode"</span><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">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.</span></span></div><div><br></div><div><div>Anyway, Chris, your thoughts are kind of on-topic but rather generic and thus actually off-topic. ;-) T<span style="font-size: 10pt">his workspace-accept-means-fileOut feature is about not destroying user input by accident. Just like #cancelSafely now integrates with the editors undo history.</span></div><div><br></div></div><div><span style="font-size: 10pt">Best,</span><br></div><div>Marcel</div><div class="mb_sig"></div>

                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">

                        <p style="color: #AAAAAA; margin-top: 10px;">Am 23.01.2022 09:06:47 schrieb Chris Muller <ma.chris.m@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi,

<br>

<br>Okay.  Glad to know there's a preference for that.  For the next

<br>release, I'll make a proposal to upgrade this preference to a more

<br>broad "pure objects mode" where the external world (e.g., filesystem)

<br>can remain completely insulated away, and treat users to a pure

<br>"object land" and, sure, there can be a designed portal for access to

<br>the layers beneath Smalltalk like the filesystem,  os processes,

services, cron, etc.

<br>

<br>Best,

<br>  Chris

<br>

<br>

<br>

<br>On Sun, Jan 23, 2022 at 1:58 AM Marcel Taeumel <marcel.taeumel@hpi.de> wrote:

<br>>

<br>> Hi Chris --

<br>>

<br>> > The above is how it used to work [...]

<br>>

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

<br>>

> > Currently, "cancel" in an Inspector bottom pane does nothing, which is kind of confusing, since the option is actually on the menu.

<br>>

<br>> Thanks. Fixed.

<br>>

> > ... oh no! While testing this, I just noticed Workspaces now force you to save out to the external filesystem!

<br>>

> Nobody is forced here. xD Just disable that preference in the preferences. It's also in the wizard. "Workspace fileOutOnAccept".

<br>>

<br>> Best,

<br>> Marcel

<br>>

<br>> Am 23.01.2022 04:00:30 schrieb Chris Muller <asqueaker@gmail.com>:

<br>>

<br>> Hi Marcel,

<br>>

> > I don't understand what you are talking about. Both "accept" and "cancel" have still consistent and predictable behaviors.

<br>>

<br>> Strictly from a user's perspective and not the responsibilities or

<br>> implementation, when:

<br>>

<br>> 1) the user edits their useful contents

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

<br>> 4) user presses Cancel, contents reverts to last-accepted contents

<br>> (from step 2).

<br>>

<br>> The above is how it used to work in Workspaces, and how it should work

<br>> by default in _every_ text Model that doesn't override Accept and

<br>> Cancel to do something else. It's a predictable and even quite useful

<br>> behavior for workspaces for keeping scratch notes or long-term

<br>> Inspectors or Explorers during long dev / debugging sessions involving

> a specific object.

<br>>

> > The only "new thing", which was already there in 5.3, is maybe #textEdited: where models can directly intercept typed contents and use them.

<br>>

<br>> Currently, "cancel" in an Inspector bottom pane does nothing, which is

<br>> kind of confusing, since the option is actually on the menu. But,

<br>> you're right, Cancel only works in Workspaces in 5.3, not Inspectors

<br>> or Explorers. But, it should! So, it's technically not a regression

> for this release. However...

<br>>

<br>> ... oh no! While testing this, I just noticed Workspaces now force

<br>> you to save out to the external filesystem! I must've missed the

<br>> discussion about this change. This is a *really negative* change to

<br>> the IDE that goes far beyond "I work this way, you work that way." It

<br>> establishes a new precedent that will (mis)lead new users to establish

<br>> bad habits, IMO. I've tried to explain in past discussions how

<br>> designing the seam between the image and the external world

<br>> haphazardly is a mistake. Hopefully we'll consider an alternative to

<br>> that. At a minimum, it should not be activated by "Accept" but a

<br>> separate, explicit menu item (on the extras menu, not the primary) and

> with no hotkey. There are good IDE design reasons for doing this...

<br>>

<br>> Best,

<br>> Chris

<br>>

<br></asqueaker@gmail.com></marcel.taeumel@hpi.de></div></blockquote></div>