Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge tim@rowledge.org:

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

Christoph, a tool that you might like to think about here is a preferences file loader that works like an MC merge tool. Read the prefs file(s), open a browser of some form that shows which ones are changed, added, removed. Allow user to choose which to load.

On 2021-11-27, at 10:31 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

Hi Marcel,

...

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph.

Not yet convinced. :-) The preference wizard is undeniably a very helpful tool for customizing your image, but going through all the pages still costs me some time. If there is any preference we can make more convenient by default, this will also make the Squeak setup more convenient for people.

In addition, in many contexts, the preference will not show up in prepared images for a specific application or Etoys project.

What can we lose by conducting this discussion? :-)

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 23. November 2021 09:44:29 An: squeak-dev Betreff: Re: [squeak-dev] Default preferences

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

...

Am 23.11.2021 00:13:44 schrieb tim Rowledge tim@rowledge.org:

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has an inferiority complex, but not a very good one.

Apologies for being unclear; I wasn't referring to any changes you are making to the preferenceswhizzard but rather suggesting a tool you might like to try making to enable loading a preferences file operate a bit like merging an MC package version.

I agree that there are a number of essentially redundant preferences that we should remove, and indeed I've ranted about that several times over the decades...

On 2021-11-27, at 12:21 PM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

Hi Tim,

I know this tool and also use it by myself. And it is not my goal to enforce my personal preferences in the Trunk image. I'm just wondering which changes would be appropriate to improve the first impression of Squeak for newcomers or people that do not spend any time going through the preference wizard or browser.

Many of the preferences I have listed below just function as feature flags - they enable additional features of the system which are hidden otherwise. I totally respect that some people do not want to switch to an alternative interaction model (e.g., mouseOverForKeyboardFocus), but other preferences such as "Show annotation pane in the debugger" just look like something to me which has been added before a feature was considered stable, or because any conversation user requested an option to turn it off. But honestly, I simply do why you would ever want to turn feature flags like this off under normal circumstances. But I am happy to learn new perspectives. :-)

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Samstag, 27. November 2021 20:28:22 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Default preferences

Christoph, a tool that you might like to think about here is a preferences file loader that works like an MC merge tool. Read the prefs file(s), open a browser of some form that shows which ones are changed, added, removed. Allow user to choose which to load.

...

On 2021-11-27, at 10:31 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

Hi Marcel,

...

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph.

Not yet convinced. :-) The preference wizard is undeniably a very helpful tool for customizing your image, but going through all the pages still costs me some time. If there is any preference we can make more convenient by default, this will also make the Squeak setup more convenient for people.

In addition, in many contexts, the preference will not show up in prepared images for a specific application or Etoys project.

What can we lose by conducting this discussion? :-)

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 23. November 2021 09:44:29 An: squeak-dev Betreff: Re: [squeak-dev] Default preferences

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

...

Am 23.11.2021 00:13:44 schrieb tim Rowledge tim@rowledge.org:

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has an inferiority complex, but not a very good one.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Starbucks are, of course, run by the Caffeinatti.

Could be just me, but I always hide flaps - would it be something for the PreferenceWizardMorph? Or hiding some menus - like Projects?

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Thanks,

^[^ Jaromir --

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge <tim at rowledge.org>:

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

Another brainstorm...

Release an image containing Projects that express different preference Idioms. (Iirc preferences are/can be project specific).

I do not use them, but I think flaps and other older squeakisms are fascinating and fun and absolutely should be presented forever.

Heck....emacs has snippets for various languages....a flap where I could pull a smalltalk snippet into a workspace would be handy.

But then, I think Tom's Window Manager (twm) is a crown jewel of X

tty

---- On Sat, 27 Nov 2021 16:17:32 -0500 Christoph.Thiede@student.hpi.uni-potsdam.de wrote ----

I always hide flaps - would it be something for the PreferenceWizardMorph?

Me too, good point.

Or hiding some menus - like Projects?

If we find a compact UI for this, it could go into the PWM, too.

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Ah, thank you! :-) Marcel already asked me to do this. Will do this definitely before the next release, just wanted to clean up some things in SIT before ...

Best, Christoph

Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von mail@jaromir.net mail@jaromir.net Gesendet: Samstag, 27. November 2021 21:16:45 An: squeak-dev@lists.squeakfoundation.org; Taeumel, Marcel Betreff: Re: [squeak-dev] Default preferences   Could be just me, but I always hide flaps - would it be something for the PreferenceWizardMorph? Or hiding some menus - like Projects?

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Thanks,

^[^ Jaromir   --

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge <tim at rowledge.org>:

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

If there was any chance to figure out what's actually better for any given user, we could change the defaults to those better values. Unfortunately, to my knowledge, there is often not. Such complex systems tend have their own "look-and-feel" overall, which users have to learn somehow.

So, we can at least keep the existing UX stable to not annoy long-term users, who would then have to look up preferences they never cared about. Yes, there are places where we can (and did) sneak in new features. "Interactive Print-it" comes to mind. I am happy that there weren't too many complaints so that we can keep it enabled by default.

Here is another example. I would love to make "Colorful windows" the default because it makes multitasking in Squeak so much easier (e.g., pre-attentive vision, color groups etc.). Yet, I understand the heuristics that most systems out there don't do that. And we do not want to scare off the new customers. :-) The preference wizard felt like a compromise I could live with. Yet, I bet that many users do not even try to work with colorful windows. So they will never figure out the beauty and efficiency of it. At least, this is want I think. And I know that. There are no studies on "colorful windows", right? So, we cannot know exactly.

Don't get me started on a "Novice Mode". There is even research on why this is not a good idea. Only "novices" and "experts". Only two bins. Sure.

So, what can we do? Make the system's concepts discoverable. Once users learn about (domain-specific) vocabulary, they will not only get better in using the system, but also in what to look for. Such as when searching an option in the PreferencesBrowser or the HelpBrowser.

Teaching the vocabulary is key. Not the default values for your or mine favorite preferences.

Best, Marcel Am 27.11.2021 23:58:45 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Timothy,

Iirc preferences are/can be project specific

Isn't that at least partially broken?

Anyway, I like your idea of different presets - but not sure whether they deserve separate manifested projects. The preference wizard is great for previewing settings in real-time.

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org Gesendet: Samstag, 27. November 2021 23:02:53 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] Default preferences   Another brainstorm...

Release an image containing Projects that express different  preference Idioms.  (Iirc preferences are/can be project specific).

I do not use them, but I think flaps and other older squeakisms are fascinating and fun and absolutely should be presented forever.

Heck....emacs has snippets for various languages....a flap where I could pull a smalltalk snippet into a workspace would be handy.

But then, I think Tom's Window Manager (twm) is a crown jewel of  X

tty

---- On Sat, 27 Nov 2021 16:17:32 -0500 Christoph.Thiede@student.hpi.uni-potsdam.de wrote ----

I always hide flaps - would it be something for the PreferenceWizardMorph?

Me too, good point.

Or hiding some menus - like Projects?

If we find a compact UI for this, it could go into the PWM, too.

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Ah, thank you! :-) Marcel already asked me to do this. Will do this definitely before the next release, just wanted to clean up some things in SIT before ...

Best, Christoph Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]> im Auftrag von mail@jaromir.net [mailto:mail@jaromir.net] <mail@jaromir.net [mailto:mail@jaromir.net]> Gesendet: Samstag, 27. November 2021 21:16:45 An: squeak-dev@lists.squeakfoundation.org [mailto:squeak-dev@lists.squeakfoundation.org]; Taeumel, Marcel Betreff: Re: [squeak-dev] Default preferences   Could be just me, but I always hide flaps - would it be something for the PreferenceWizardMorph? Or hiding some menus - like Projects?

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Thanks,

^[^ Jaromir   --

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de] wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge <tim at rowledge.org>:

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Hackers have kernel knowledge.

Am 30.11.2021 um 09:17 schrieb Stéphane Rollandin:

A long time ago, when I first discoverd Squeak, I was blown away by 'The Worlds of Squeak', which came right within the default image. Nowadays we just get a grey background with a welcome window. If it is for the sake of 'seriousness' well I think it is seriously misguided.

Same here. Blown away by 'The Worlds of Squeak' (still have a 3.6 image) and I think the same about the 'seriousness'.

Cheers,

Herbert

--==CelesteAttachment19865== Content-type: text/plain;charset=UTF-8

Hi all,

[...] to improve the initial experience for new Squeakers even more!

I'm still a beginner and for me the default preferences were fine as far as my initial impression :) And I'm still happy with the default ones (except 1 or 2). So Preferences were not my (beginner's) main problem; for a beginner, the whole Smalltalk and the OOP concept is a challenge :) (Other story may be new customers/users looking for an alternative; I'm not referring to this scenario).

So, for example, I'd greatly appreciate a tool to help a beginner develop an intuition about objects (I chose Squeak to study OOP); an object is usually defined as an entity with some states (variables) and capabilities (methods). However, no tool displays this simple concept all in one window!

Inspector shows just the states, Browsers just the methods. I recently came across Inspector Browser, which combines Inspector and Browser, but it's still not enough: for example, you get no visual clue that the object has access not only to its methods, but also to the methods of its superclasses.

I enclose a screenshot of what I'd fancy as such Object Inspector :)

So my suggestion would be to offer such kind of tool(s) to beginners and promote it maybe via the Wizzard or a preference.

Thanks,

~~~ ^[^ -- Jaromir

Sent from Squeak Inbox Talk

On 2021-11-30T12:49:04+01:00, marcel.taeumel@hpi.de wrote:

Hi Herbert, Hi StC)phane --

...

B I was blown away by 'TheB Worlds of Squeak', which came right within the default image.

Thanks to Christoph's efforts in rescuing "TheB Worlds of Squeak", we can have such a presentation in the next release -- without compromising much of the current level of "seriousness" :-)

Best, Marcel Am 30.11.2021 10:16:31 schrieb Herbert KC6nig <herbertkoenig at gmx.net>:

Am 30.11.2021 um 09:17 schrieb StC)phane Rollandin:

...

A long time ago, when I first discoverd Squeak, I was blown away by 'The Worlds of Squeak', which came right within the default image. Nowadays we just get a grey background with a welcome window. If it is for the sake of 'seriousness' well I think it is seriously misguided.

Same here. Blown away by 'The Worlds of Squeak' (still have a 3.6 image) and I think the same about the 'seriousness'.

Cheers,

Herbert

Hi Timothy,

then I will gladly generate a PreferencesHelp

Your contributions for documentation on Squeak are very welcome, but IMHO separate help documents that mirror the structure of the subject are not the most efficient way to go. What I think could help us better would be:

* A short summary of preferences that are relevant for different user groups, such as newbies, developers, or core developers - our current general-purpose summary is the preference wizard, but it might benefit from some minor refinements. Hypothetically, we could model different user roles here with a small drop-down menu or something like this - but this should be discussed beforehand on the list. * Better categories for all the existing preferences - for example, some preferences are in the Morphic category which IMHO would belong to 'tools' instead. The current inconsistent spelling is also slightly distracting. * A list of preferences that we should deprecate - beware, there is already deleteUnusedPrefs.cs on the list. * Maybe some improved helpStrings of the preference items themselves.

You can see all existing preferences in the preference browser if you select the "--all--" category. If you really need this, you can query them via "Preferences allPreferences".

But IMHO separate help documents should be used with caution - in my experience, they are looked up significantly rarer than help content that is integrated right into the domain (method comments, class comments, tooltips, maybe help buttons). Interactivity is a great strength of Squeak and Morphic. We should not impair it by introducing additional spatial or semantic distances [1]. Plus, separate content tends to get out of sync. Interactive tutorials that guide you through a tool when you open it the first time would be very cool if you would like to engage more in this field.

Anyway, this is just my personal view, and I'm happy whenever you can present me an opposite one. :-)

Best, Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org Gesendet: Samstag, 27. November 2021 22:51 Uhr An: squeak-dev@lists.squeakfoundation.org Cc: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] Default preferences

Not to interrupt,

but if an output of all preferences (along with method category and 'target' if such thing exist) then I will gladly generate a PreferencesHelp.

It may help you kind folks offload these decisions to more experienced users while reducing the amount of preferences to be considered for release purposes.

Just post a Doit for me and I will git-r-done.

Cordially

tty

---- On Sat, 27 Nov 2021 15:16:45 -0500 mail@jaromir.net wrote ----

Could be just me, but I always hide flaps - would it be something for the PreferenceWizardMorph? Or hiding some menus - like Projects?

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Thanks,

^[^ Jaromir --

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge <tim at rowledge.org>:

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

I have been piddling around with this to see what I can see to generate a starting point for thinking about this.

An obvious first step would be to show all the preferences associated with a "thing"

TextEditor

Workspace

TheWorldMainDockingBar

are just a few of the things that have preferences on them:

Transcript clear.

(SystemNavigation allMethodsSelect:[:mds |

#(preference:category:description:type: preference:categoryList:description:type:)

anySatisfy:[:s| (mds pragmaAt: s) notNil]])

do:[:m |

Transcript show: (m methodSymbol)  ; cr.

m compiledMethod pragmas do:[:pragma |

Transcript show: ((pragma methodClass name)copyReplaceAll:'class' with:'  '); cr;cr.

Transcript show: (pragma);cr;cr;cr;cr.]]

Per what Tim writes below...

We should be able to automate that task by modifying "something" programatically.

Also....

Would it make sense to add the preferences toggling directly to the menus for specific things?

fileOutFilePath and fileOutOnAccept strike me as useful things to be viewed and modified in any Workspace.

cordially,

---- On Sat, 27 Nov 2021 23:29:47 -0500 tim Rowledge tim@rowledge.org wrote ----

On 2021-11-27, at 2:56 PM, Thiede, Christoph mailto:Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

But IMHO separate help documents should be used with caution - in my experience, they are looked up significantly rarer than help content that is integrated right into the domain (method comments, class comments, tooltips, maybe help buttons).

Something that would probably help here is making sure that when a class (or group of classes etc) has a HelpBrowser section, we reference that Help stuff from the class(es) & method comments. We have the ability to link a bit of text to class comments, definitions, methods and so on, so maybe we could add one to a HelpBrowser section?

Hmm, a few minutes whacking suggests that a simple subclass of TextAction would do the job, along with a bit more understanding of the right way to open a help browser on a suitable topic. Maybe tomorrow.

tim -- tim Rowledge; mailto:tim@rowledge.org; http://www.rowledge.org/tim Objects are closer than they appear.

It works. I highlighted 'TerseGuideHelp' and hit <alt>6 to select 'Link to Help' and the resulting hyperlink opens the terse guide help.

Dave

On Sun, Nov 28, 2021 at 02:46:24PM -0800, tim Rowledge wrote:

OK, a few more minutes banging randomly on a keyboard before lunch and I can offer this very simple idea as an example -

...

On 2021-11-27, at 8:29 PM, tim Rowledge tim@rowledge.org wrote:

Hmm, a few minutes whacking suggests that a simple subclass of TextAction would do the job, along with a bit more understanding of the right way to open a help browser on a suitable topic. Maybe tomorrow.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VDP: Violate Design Parameters

Hi Marcel

While I agree, and maybe I am missing something here, but a per-thing documentation approach, while valuable, does not lend itself to "big picture" use patterns.

While I do not really care if Doc is incorporated into squeak someday, I use it precicely for these big-picture things so that I can understand a package.

I offer back in case somebody finds the idea intriguing or useful.

Ideally, and I have no idea how this would happen, the atomized things "should" organize themselves into the big-picture documentation.

However, getting Xtreams-Parsing to ask the PEG grammars, PEGActors etc to organize themselves into an explanation of how to use the thing is beyond my skills.

Same for XMLSax/Parser/Document/Node etc. So, before "flailing around" looking for relationships between classes/methods/objects, I start documenting in words, in Emacs and

coalesce the thing into something I can use go forward.

Doc is baby steps in that direction as I think about the problem going forward.

That work , I can import to CustomHelp useing the Doc converters and it is readily available when I need it.

Pretty every question answered here by the team ends up in Doc-SqueakHOWTO for me to use later (Eliot, your method of substring extraction from a stream is next (:)

Squeak loses mind-share because of "the documentation problem" and that needs to be corrected because it is a beautiful coding idiom.

Now, this "preferences help" is my way of beginning to grok the big picture about Preferences via reading it, vs discovering it.  Going forward, this prelimary study will slim down my exploration time

by presenting at a glance, What has preferences and in the scope of What has, What does it do. Also, I was observing a discussion on Preferences and thought it would be a win-win for me and the team IF they choose to use any of it.

Cordially,

---- On Mon, 29 Nov 2021 03:31:39 -0500 Marcel Taeumel marcel.taeumel@hpi.de wrote ----

Hi all --

Please let us all improve the in-image documentation, which should be as close as possible to the things they document. At best, "these things" document themselves through their name or other distinctive features.

***

If you have an idea on how to clarify the description of a preference, go ahead and do it. Or at least mention it on this list. :-)

If you have an idea on a new category (or tag) for a preference, go ahead and add it. Or at least mention it on this list. ;-)

All this textual data is (or is expected to be) covered by the search feature in the PreferenceBrowser. So, if you favorite buzzword is not part of that data, consider adding it in the description, name, or category/tag list of that preference.

Thank you.

Best,

Marcel

P.S.: The preference wizard is good for browsing. The preference browser is good for searching. Hehe. :-)

Am 29.11.2021 01:24:11 schrieb David T. Lewis mailto:lewis@mail.msen.com:

It works. I highlighted 'TerseGuideHelp' and hit 6 to select 'Link to Help' and the resulting hyperlink opens the terse guide help.

Dave

On Sun, Nov 28, 2021 at 02:46:24PM -0800, tim Rowledge wrote:

OK, a few more minutes banging randomly on a keyboard before lunch and I can offer this very simple idea as an example -

...

On 2021-11-27, at 8:29 PM, tim Rowledge wrote:

Hmm, a few minutes whacking suggests that a simple subclass of TextAction would do the job, along with a bit more understanding of the right way to open a help browser on a suitable topic. Maybe tomorrow.

tim

tim Rowledge; mailto:tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VDP: Violate Design Parameters

Hi Marcel

thx

In no particular order:

Sure, if that is not possible or feasible, a documentation-only "thing" can be introduced like a "CustomHelp" class. Yet, that's harder to maintain and integrate. :-) Unless derived from existing information automatically such as in ClassAPIHelpTopic. Could work for preferences, too. There is a lot of existing documentation (i.e., texts) to expose/integrate.

The email board is a huge repo of documentation. Lately, StackExchange is very useful.

The bold part was my first stab at Doc/SeasideDoc    http://menmachinesmaterials.com/SeasideDoc%C2%A0; It did not provide useful information (meaning, organized so as to minimize grok time) so I removed it from the menu.

(:

While I support your approach, the "proof is in the pudding with the chicken and the egg problem".

Perhaps we are talking about two different things.

In image help tends to be stuff I need as I am coding....that finding a substring in a Stream problem does not exist in squeak, or if it does, it is not easily discoverable.

I fully support what you are talking about for this use-case.

Out of Image support, unfortunately, is what I have to rely on to get most things done. Especially stuff I have never learned before or reminders on things I have done, but forgotten.

My thinking is to

1. reduce barriers to creating content...just jot it down "somewhere" in some place that seems appropriate

1.a edit, organize, merge as makes sense.

2. create ability to import it in-image easily.

3. reference that inline.

4. create ability to build books easily.

That second approach is a personal project to help me continue to learn and remember.

I literally use it every day I code. <---This statement is what I refer to as "the proof is in the pudding"

Where, in my "meager" coding flow, do I find myself turning to for information?

Since I can import my Doc work into CustomHelp (or view it on the web, or github) I find myself turning to it more and more as I work .

TL;DR

I find the current squeak help to be insufficient , and hard to find.

So I am teaching myself the platform using a documentation approach that works for me.

Of course, The Squeak team is welcome to any and all content to use as they see fit.

However, if the team does not want it, that is fine too.

Cordially,

t

---- On Mon, 29 Nov 2021 10:15:32 -0500 Marcel Taeumel marcel.taeumel@hpi.de wrote ----

Hi Timothy --

I think we should optimize for how users can discover and understand the system's domain concepts first and foremost. Digging into a single concept's configuration space (i.e., its preferences) comes second if at all. The wizard tries to improve the first impression and to "smooth out the big determents" such as colors. Hehe.

While I agree, and maybe I am missing something here, but a per-thing documentation approach, while valuable, does not lend itself to "big picture" use patterns.

Yes, the "big picture" can be challenging to document. If you are lucky, there is a "thing" in the system that represents the bigger idea. In Morphic, for example, I can attach generic documentation to the "Morph" class as well. Maybe within that documentation point to "MorphicEventDispatcher" to keep going. The "DOCUMENTATION" protocol in RxParser class is also very close to the "thing" it documents. For XML, the XMLDocument would be my personal point of entry when wanting to learn about XML support. In its class comment, you could point to other classes of interest. Maybe take a look at FFI's "ExternalPool" class comment.

Sure, if that is not possible or feasible, a documentation-only "thing" can be introduced like a "CustomHelp" class. Yet, that's harder to maintain and integrate. :-) Unless derived from existing information automatically such as in ClassAPIHelpTopic. Could work for preferences, too. There is a lot of existing documentation (i.e., texts) to expose/integrate.

***

Now, this "preferences help" is my way of beginning to grok the big picture about Preferences via reading it, vs discovering it. Going forward, this preliminary study will slim down my exploration time by presenting at a glance, What has preferences and in the scope of What has, What does it do.

Totally. Different. Story. :-) Not like documenting, e.g., XMLDocument at all.

I think that if a user wants to change a preference about, say, "keyboard shortcuts", they can type "keyboard" and/or "shortcuts" in the search field and quickly browse the list of results. Not that hard. Typing "workspace" right now produces good results. Try it. The primary challenge is how to teach that vocabulary in the first place. And to attach that vocabulary to the searched space.

The PreferenceWizard simplifies things a bit. Keeping it browse-able. And teaches important vocabulary at the same time. After looking through the things in the wizard, you might be able to type in better queries in the preferences browser to find more preferences.

We want to teach domain vocabulary, not each domain's configuration space (i.e., not the preferences).

***

Okay. Say that you want to write/hard-code a new help topic to teach people about relevant preferences. Maybe take the wizard's approach into consideration and argue for or against it. If you find better categories, then we can also improve the wizard.

Here are the wizard pages:

#initializePage01Themes

#initializePage02Visuals

#initializePage02bVisualsMore

#initializePage03Interaction

#initializePage04InteractionMore

#initializePage05Tools

***

So, we have to teach users about the system's vocabulary. Then they can enter useful queries into search fields such as the one in the PreferenceBrowser. Then they can find what they are looking for. That's why I pointed to optimizing preference descriptions etc. Same goes for the HelpBrowser. Add topics that aggregate existing infos in a meaningful way to extend the search space. Keep the amount of topics with hand-crafted content to a minimum.

Best,

Marcel

Am 29.11.2021 14:48:45 schrieb gettimothy mailto:gettimothy@zoho.com:

Hi Marcel

While I agree, and maybe I am missing something here, but a per-thing documentation approach, while valuable, does not lend itself to "big picture" use patterns.

While I do not really care if Doc is incorporated into squeak someday, I use it precicely for these big-picture things so that I can understand a package.

I offer back in case somebody finds the idea intriguing or useful.

Ideally, and I have no idea how this would happen, the atomized things "should" organize themselves into the big-picture documentation.

However, getting Xtreams-Parsing to ask the PEG grammars, PEGActors etc to organize themselves into an explanation of how to use the thing is beyond my skills.

Same for XMLSax/Parser/Document/Node etc. So, before "flailing around" looking for relationships between classes/methods/objects, I start documenting in words, in Emacs and

coalesce the thing into something I can use go forward.

Doc is baby steps in that direction as I think about the problem going forward.

That work , I can import to CustomHelp useing the Doc converters and it is readily available when I need it.

Pretty every question answered here by the team ends up in Doc-SqueakHOWTO for me to use later (Eliot, your method of substring extraction from a stream is next (:)

Squeak loses mind-share because of "the documentation problem" and that needs to be corrected because it is a beautiful coding idiom.

Now, this "preferences help" is my way of beginning to grok the big picture about Preferences via reading it, vs discovering it.  Going forward, this prelimary study will slim down my exploration time

by presenting at a glance, What has preferences and in the scope of What has, What does it do. Also, I was observing a discussion on Preferences and thought it would be a win-win for me and the team IF they choose to use any of it.

Cordially,

---- On Mon, 29 Nov 2021 03:31:39 -0500 Marcel Taeumel mailto:marcel.taeumel@hpi.de wrote ----

Hi all --

Please let us all improve the in-image documentation, which should be as close as possible to the things they document. At best, "these things" document themselves through their name or other distinctive features.

***

If you have an idea on how to clarify the description of a preference, go ahead and do it. Or at least mention it on this list. :-)

If you have an idea on a new category (or tag) for a preference, go ahead and add it. Or at least mention it on this list. ;-)

All this textual data is (or is expected to be) covered by the search feature in the PreferenceBrowser. So, if you favorite buzzword is not part of that data, consider adding it in the description, name, or category/tag list of that preference.

Thank you.

Best,

Marcel

P.S.: The preference wizard is good for browsing. The preference browser is good for searching. Hehe. :-)

Am 29.11.2021 01:24:11 schrieb David T. Lewis mailto:lewis@mail.msen.com:

It works. I highlighted 'TerseGuideHelp' and hit 6 to select 'Link to Help' and the resulting hyperlink opens the terse guide help.

Dave

On Sun, Nov 28, 2021 at 02:46:24PM -0800, tim Rowledge wrote:

OK, a few more minutes banging randomly on a keyboard before lunch and I can offer this very simple idea as an example -

...

On 2021-11-27, at 8:29 PM, tim Rowledge wrote:

Hmm, a few minutes whacking suggests that a simple subclass of TextAction would do the job, along with a bit more understanding of the right way to open a help browser on a suitable topic. Maybe tomorrow.

tim

tim Rowledge; mailto:tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VDP: Violate Design Parameters

Hi Jaromir --

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel Am 07.12.2021 10:01:48 schrieb mail@jaromir.net mail@jaromir.net: Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge :

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:35 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel

Am 07.12.2021 10:33:32 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Jaromir --

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel

Am 07.12.2021 10:01:48 schrieb mail@jaromir.net mail@jaromir.net: Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge :

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:59 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)

Best, Marcel

Am 07.12.2021 10:48:58 schrieb Jaromir Matas mail@jaromir.net: Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:35 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel

Am 07.12.2021 10:33:32 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Jaromir --

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel

Am 07.12.2021 10:01:48 schrieb mail@jaromir.net mail@jaromir.net: Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge :

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

Checked already 😊 Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic) Thanks!

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 11:52 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)

Best, Marcel

Am 07.12.2021 11:05:36 schrieb Jaromir Matas mail@jaromir.net: I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:59 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)

Best, Marcel

Am 07.12.2021 10:48:58 schrieb Jaromir Matas mail@jaromir.net: Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:35 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel

Am 07.12.2021 10:33:32 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Jaromir --

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel

Am 07.12.2021 10:01:48 schrieb mail@jaromir.net mail@jaromir.net: Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge :

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

-------------- next part -------------- An HTML attachment was scrubbed... URL:

Thanks! I’m AFK and reread later :)

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 12:22 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Best, Marcel

Am 07.12.2021 11:56:45 schrieb Jaromir Matas mail@jaromir.net: Checked already 😊 Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic) Thanks!

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 11:52 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)

Best, Marcel

Am 07.12.2021 11:05:36 schrieb Jaromir Matas mail@jaromir.net: I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:59 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)

Best, Marcel

Am 07.12.2021 10:48:58 schrieb Jaromir Matas mail@jaromir.net: Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Tuesday, December 7, 2021 10:35 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel

Am 07.12.2021 10:33:32 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Jaromir --

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel

Am 07.12.2021 10:01:48 schrieb mail@jaromir.net mail@jaromir.net: Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel@hpi.de wrote:

Hi all --

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel Am 23.11.2021 00:13:44 schrieb tim Rowledge :

...

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

...

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.

-------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Jaromir,

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Sounds wrong to me, nice catch! We should look into this.

Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse.

We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?

If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

This would be very welcome! We should also unify the Uppercase/lowercase of all categories.

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von mail@jaromir.net mail@jaromir.net Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr An: squeak-dev@lists.squeakfoundation.org; Taeumel, Marcel Betreff: Re: [squeak-dev] Default preferences

Hi Marcel,

...

No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:

self halt. self halt. self halt

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.

This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)

I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)

Apologies for such a long message.

Thanks a lot,

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T12:21:45+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

...

No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Best, Marcel Am 07.12.2021 11:56:45 schrieb Jaromir Matas <mail at jaromir.net>: Checked already 😊 Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic) Thanks!

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 11:52 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)

Best, Marcel Am 07.12.2021 11:05:36 schrieb Jaromir Matas <mail at jaromir.net>: I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:59 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

...

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)

Best, Marcel Am 07.12.2021 10:48:58 schrieb Jaromir Matas <mail at jaromir.net>: Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:35 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel Am 07.12.2021 10:33:32 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>: Hi Jaromir --

...

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel Am 07.12.2021 10:01:48 schrieb mail at jaromir.net <mail at jaromir.net>: Hi all --

...

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:

> Hi all --
>
> There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
>
> Best,
> Marcel
> Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> >> 1. Windowing
> >> Personally, the first thing I do in every new image is to enable these prefs:
> >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
>
> Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
>
> > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
>
> But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
>
>
> >> 4. Editing
> >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> >> - Enclose selection with brackets -> true
>
> Again, very not OK for me.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Hackers have kernel knowledge.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
>







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

Hi Christoph --

We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us.

Well, I play the piano with both hands. There are users that have both hands on the keyboard most of the time. Then there are users that maybe only use one hand for the keyboard, the other one for the mouse. I am not sure whether you can have both hands on the mouse. Consequently, there are different groups of users. Until now, Squeak's keyboard-only support is rather sketchy. We should work on that.

What's the benefit of attaching the window to the mouse? Resizing and positioning. One does not have to point to the window grips in order to do that. How would the user resize a window in keyboard mode? Yeah. Maybe that's the question we should answer.

If we manage to keep keyboard-based and mouse-base interaction modes separate, we might even enable that "attach tools to cursor" preference by default. Because it would not annoy the keyboard people. Just at thought.

It's not primarily about one person's "intuition" ... it's about finding balance and trade-offs.

Best, Marcel Am 07.12.2021 22:30:09 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Jaromir,

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Sounds wrong to me, nice catch! We should look into this.

Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse. We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?

If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

This would be very welcome! We should also unify the Uppercase/lowercase of all categories.

Best, Christoph

Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von mail@jaromir.net mail@jaromir.net Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr An: squeak-dev@lists.squeakfoundation.org; Taeumel, Marcel Betreff: Re: [squeak-dev] Default preferences   Hi Marcel,

...

No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:

self halt. self halt. self halt

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.

This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)

I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)

Apologies for such a long message.

Thanks a lot,

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

~~~ ^[^    Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T12:21:45+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

>No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Best, Marcel Am 07.12.2021 11:56:45 schrieb Jaromir Matas <mail at jaromir.net>: Checked already 😊 Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic) Thanks!   From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 11:52 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences   Hi Jaromir --   Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)   Best, Marcel Am 07.12.2021 11:05:36 schrieb Jaromir Matas <mail at jaromir.net>: I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.   From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:59 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences   Hi Jaromir --   Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

...

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)   Best, Marcel Am 07.12.2021 10:48:58 schrieb Jaromir Matas <mail at jaromir.net>: Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.   I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir   From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:35 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences   My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?   Best, Marcel Am 07.12.2021 10:33:32 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>: Hi Jaromir --

...

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.   Best, Marcel Am 07.12.2021 10:01:48 schrieb mail at jaromir.net <mail at jaromir.net>: Hi all --

...

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:

> Hi all --
>
> There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
>
> Best,
> Marcel
> Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> >> 1. Windowing
> >> Personally, the first thing I do in every new image is to enable these prefs:
> >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
>
> Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
>
> > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
>
> But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
>
>
> >> 4. Editing
> >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> >> - Enclose selection with brackets -> true
>
> Again, very not OK for me.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim]
> Hackers have kernel knowledge.
>
>
>
> 

Hi Christoph, all,

A small suggestion - current implementation attaches the new window centered around the cursor - I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient; Here's the change:

attachMorph: m "Position the center of the given morph under this hand, then grab it. This method is used to grab far away or newly created morphs." | delta | self releaseMouseFocus. "Break focus" self showTemporaryCursor: nil. delta := m bounds extent // 5. <--------------------------- replace 2 with 5 m position: (self position - delta). m formerPosition: m position. targetOffset := m position - self position. self addMorphBack: m.

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T21:30:09+00:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi Jaromir,

...

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Sounds wrong to me, nice catch! We should look into this.

Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse.

We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?

If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)

...

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

This would be very welcome! We should also unify the Uppercase/lowercase of all categories.

Best,

Christoph

---

Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von mail at jaromir.net <mail at jaromir.net> Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr An: squeak-dev at lists.squeakfoundation.org; Taeumel, Marcel Betreff: Re: [squeak-dev] Default preferences

Hi Marcel,

...

...

No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:

self halt. self halt. self halt

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.

This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)

I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)

Apologies for such a long message.

Thanks a lot,

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

^[^    Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T12:21:45+01:00, marcel.taeumel at hpi.de wrote:

> Hi Jaromir --
>
>  >No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
>
> Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
>
> Best,
> Marcel
> Am 07.12.2021 11:56:45 schrieb Jaromir Matas <mail at jaromir.net>:
> Checked already 😊
> Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent
> No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> Thanks!
>
> From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> Sent: Tuesday, December 7, 2021 11:52
> To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> Subject: Re: [squeak-dev] Default preferences
>
> Hi Jaromir --
>
> Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)
>
> Best,
> Marcel
> Am 07.12.2021 11:05:36 schrieb Jaromir Matas <mail at jaromir.net>:
> I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.
>
> From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> Sent: Tuesday, December 7, 2021 10:59
> To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> Subject: Re: [squeak-dev] Default preferences
>
> Hi Jaromir --
>
> Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?
>
> > I think it happened with some dialogues as well but can’t remember now.
>
> Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)
>
> Best,
> Marcel
> Am 07.12.2021 10:48:58 schrieb Jaromir Matas <mail at jaromir.net>:
> Hi Marcel,
> I tried both do-it from the menu and via CTRL-d and they both behave erratically.
>
> I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now.
> Thanks,
> Jaromir
>
> From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> Sent: Tuesday, December 7, 2021 10:35
> To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> Subject: Re: [squeak-dev] Default preferences
>
> My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?
>
> Best,
> Marcel
> Am 07.12.2021 10:33:32 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Jaromir --
>
> > E.g. try do-it (a few times):
>
> Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.
>
> Best,
> Marcel
> Am 07.12.2021 10:01:48 schrieb mail at jaromir.net <mail at jaromir.net>:
> Hi all --
> >
> > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> >
> > Best,
> > Marcel
> I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):
>
> self halt. self halt
>
> The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)
>
> Best,
>
> ~~~
> ^[^ Jaromir
>
> Sent from Squeak Inbox Talk
>
> On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:
>
> > Hi all --
> >
> > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> >
> > Best,
> > Marcel
> > Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> > >> 1. Windowing
> > >> Personally, the first thing I do in every new image is to enable these prefs:
> > >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> > >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
> >
> > Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
> >
> > > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
> >
> > But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
> >
> >
> > >> 4. Editing
> > >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> > >> - Enclose selection with brackets -> true
> >
> > Again, very not OK for me.
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Hackers have kernel knowledge.
> >
> >
> >
> > 

Hi Marcel,

Hi Jaromir --

...

I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient

Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?

The main reason I find it more convenient (or just less distracting) is when I open a window by clicking on a button or from the context menu near the top of the screen (or the left side) the attached window is partly outside my screen. Lower right would be even worse in this regard :) And upper left is dangerously close to the close button. But as I said, it's a small inconvenience for me and maybe even just me :)

(And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)

I won't dispute this :D I just used this place to test the offset ;)

Thanks, ~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-10T10:14:29+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

...

I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient

Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?

(And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)

Best, Marcel Am 09.12.2021 20:25:31 schrieb mail at jaromir.net <mail at jaromir.net>: Hi Christoph, all,

A small suggestion - current implementation attaches the new window centered around the cursor - I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient; Here's the change:

attachMorph: m "Position the center of the given morph under this hand, then grab it. This method is used to grab far away or newly created morphs." | delta | self releaseMouseFocus. "Break focus" self showTemporaryCursor: nil. delta := m bounds extent // 5. <--------------------------- replace 2 with 5 m position: (self position - delta). m formerPosition: m position. targetOffset := m position - self position. self addMorphBack: m.

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T21:30:09+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi Jaromir,
>
>
> > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
>
> Sounds wrong to me, nice catch! We should look into this.
>
>
> Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse.
>
> We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?
>
> If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)
>
>
> > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
>
>
> This would be very welcome! We should also unify the Uppercase/lowercase of all categories.
>
>
> Best,
>
> Christoph
>
>
> ________________________________
> Von: Squeak-dev im Auftrag von mail at jaromir.net
> Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr
> An: squeak-dev at lists.squeakfoundation.org; Taeumel, Marcel
> Betreff: Re: [squeak-dev] Default preferences
>
> Hi Marcel,
>
> >
> > >No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> >
> > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
>
> Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:
>
> self halt. self halt. self halt
>
> and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
>
> Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.
>
> This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)
>
> I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)
>
> Apologies for such a long message.
>
> Thanks a lot,
>
> PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
>
> ~~~
> ^[^ Jaromir
>
> Sent from Squeak Inbox Talk
>
> On 2021-12-07T12:21:45+01:00, marcel.taeumel at hpi.de wrote:
>
> > Hi Jaromir --
> >
> > >No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> >
> > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> >
> > Best,
> > Marcel
> > Am 07.12.2021 11:56:45 schrieb Jaromir Matas :
> > Checked already 😊
> > Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent
> > No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > Thanks!
> >
> > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > Sent: Tuesday, December 7, 2021 11:52
> > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > Subject: Re: [squeak-dev] Default preferences
> >
> > Hi Jaromir --
> >
> > Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)
> >
> > Best,
> > Marcel
> > Am 07.12.2021 11:05:36 schrieb Jaromir Matas :
> > I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.
> >
> > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > Sent: Tuesday, December 7, 2021 10:59
> > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > Subject: Re: [squeak-dev] Default preferences
> >
> > Hi Jaromir --
> >
> > Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?
> >
> > > I think it happened with some dialogues as well but can’t remember now.
> >
> > Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)
> >
> > Best,
> > Marcel
> > Am 07.12.2021 10:48:58 schrieb Jaromir Matas :
> > Hi Marcel,
> > I tried both do-it from the menu and via CTRL-d and they both behave erratically.
> >
> > I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now.
> > Thanks,
> > Jaromir
> >
> > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > Sent: Tuesday, December 7, 2021 10:35
> > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > Subject: Re: [squeak-dev] Default preferences
> >
> > My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?
> >
> > Best,
> > Marcel
> > Am 07.12.2021 10:33:32 schrieb Marcel Taeumel :
> > Hi Jaromir --
> >
> > > E.g. try do-it (a few times):
> >
> > Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.
> >
> > Best,
> > Marcel
> > Am 07.12.2021 10:01:48 schrieb mail at jaromir.net :
> > Hi all --
> > >
> > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > >
> > > Best,
> > > Marcel
> > I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):
> >
> > self halt. self halt
> >
> > The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)
> >
> > Best,
> >
> > ~~~
> > ^[^ Jaromir
> >
> > Sent from Squeak Inbox Talk
> >
> > On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:
> >
> > > Hi all --
> > >
> > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > >
> > > Best,
> > > Marcel
> > > Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> > > >> 1. Windowing
> > > >> Personally, the first thing I do in every new image is to enable these prefs:
> > > >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> > > >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
> > >
> > > Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
> > >
> > > > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
> > >
> > > But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
> > >
> > >
> > > >> 4. Editing
> > > >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> > > >> - Enclose selection with brackets -> true
> > >
> > > Again, very not OK for me.
> > >
> > > tim
> > > --
> > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > > Hackers have kernel knowledge.
> > >
> > >
> > >
> > > 

Hi Marcel, Christoph and all,

a few more notes about preferences:

(1) sortMessageCategoriesAlphabetically - my suggestion would be to place starred *extensions categories behind "normal" categories; alphabetical ordering places them all before 'accessing' etc. In case of Object for example the list starts with *Deprecated and you scroll over a lot of extension categories before you get down to "normal" categories.

(2) what is CMD-s supposed to do in the Transcript window? Currently it clears the window without a way back - undo (CMD-z) doesn't restore it. CMD-l (lowercase L) also clears the Transcript but the undo works... Help's Keyboard Shortcuts doesn't help: CMD-s is supposed to "save" (I understand diffent windows have different sets of shortcuts but Help's Keyboard Shortcuts is the only info I have - or any beginner). Why not e.g. save Transcript's window contents similarly as Workspace's contents on Accept/Save/CMD-s or make it a preference?

(3) about the "always attach to cursor" mode suggested by Christoph earlier - because currently there's no strong support of keyboard only interaction, why not make it a preference: attach on mouse events / attach always? I still find the current 'attach on mouse events' mode confusing; I don't explicitely think how I start a tool, whether using a key or the mouse, you don't even have a choce always... so my brain often expects the tool under the cursor and it shows up somewhere else :)

(4) regarding the relative position of the tool being attached and the cursor - an offset of 25% would be better than 20% because in case of a debugger notifier window the 20% offset places the cursor over the Proceed button ;)

Thanks,

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-10T10:39:34+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

Agreed. I am looking a better place to implement that 20% offset. The centered pop-up did already confuse me at times, too.

Other opinions about this?

Best, Marcel Am 10.12.2021 10:30:32 schrieb mail at jaromir.net <mail at jaromir.net>: Hi Marcel,

...

Hi Jaromir --

...

I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient

Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?

The main reason I find it more convenient (or just less distracting) is when I open a window by clicking on a button or from the context menu near the top of the screen (or the left side) the attached window is partly outside my screen. Lower right would be even worse in this regard :) And upper left is dangerously close to the close button. But as I said, it's a small inconvenience for me and maybe even just me :)

...

(And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)

I won't dispute this :D I just used this place to test the offset ;)

Thanks,

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-10T10:14:29+01:00, marcel.taeumel at hpi.de wrote:

> Hi Jaromir --
>
> > I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient
>
> Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?
>
> (And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)
>
> Best,
> Marcel
> Am 09.12.2021 20:25:31 schrieb mail at jaromir.net :
> Hi Christoph, all,
>
> A small suggestion - current implementation attaches the new window centered around the cursor - I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient; Here's the change:
>
> attachMorph: m
> "Position the center of the given morph under this hand, then grab it.
> This method is used to grab far away or newly created morphs."
> | delta |
> self releaseMouseFocus. "Break focus"
> self showTemporaryCursor: nil.
> delta := m bounds extent // 5.
> m position: (self position - delta).
> m formerPosition: m position.
> targetOffset := m position - self position.
> self addMorphBack: m.
>
>
> ~~~
> ^[^ Jaromir
>
> Sent from Squeak Inbox Talk
>
> On 2021-12-07T21:30:09+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
>
> > Hi Jaromir,
> >
> >
> > > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
> >
> > Sounds wrong to me, nice catch! We should look into this.
> >
> >
> > Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse.
> >
> > We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?
> >
> > If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)
> >
> >
> > > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
> >
> >
> > This would be very welcome! We should also unify the Uppercase/lowercase of all categories.
> >
> >
> > Best,
> >
> > Christoph
> >
> >
> > ________________________________
> > Von: Squeak-dev im Auftrag von mail at jaromir.net
> > Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr
> > An: squeak-dev at lists.squeakfoundation.org; Taeumel, Marcel
> > Betreff: Re: [squeak-dev] Default preferences
> >
> > Hi Marcel,
> >
> > >
> > > >No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > >
> > > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> >
> > Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:
> >
> > self halt. self halt. self halt
> >
> > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
> >
> > Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.
> >
> > This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)
> >
> > I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)
> >
> > Apologies for such a long message.
> >
> > Thanks a lot,
> >
> > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
> >
> > ~~~
> > ^[^ Jaromir
> >
> > Sent from Squeak Inbox Talk
> >
> > On 2021-12-07T12:21:45+01:00, marcel.taeumel at hpi.de wrote:
> >
> > > Hi Jaromir --
> > >
> > > >No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > >
> > > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> > >
> > > Best,
> > > Marcel
> > > Am 07.12.2021 11:56:45 schrieb Jaromir Matas :
> > > Checked already 😊
> > > Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent
> > > No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > Thanks!
> > >
> > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > Sent: Tuesday, December 7, 2021 11:52
> > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > Subject: Re: [squeak-dev] Default preferences
> > >
> > > Hi Jaromir --
> > >
> > > Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)
> > >
> > > Best,
> > > Marcel
> > > Am 07.12.2021 11:05:36 schrieb Jaromir Matas :
> > > I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.
> > >
> > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > Sent: Tuesday, December 7, 2021 10:59
> > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > Subject: Re: [squeak-dev] Default preferences
> > >
> > > Hi Jaromir --
> > >
> > > Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?
> > >
> > > > I think it happened with some dialogues as well but can’t remember now.
> > >
> > > Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)
> > >
> > > Best,
> > > Marcel
> > > Am 07.12.2021 10:48:58 schrieb Jaromir Matas :
> > > Hi Marcel,
> > > I tried both do-it from the menu and via CTRL-d and they both behave erratically.
> > >
> > > I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now.
> > > Thanks,
> > > Jaromir
> > >
> > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > Sent: Tuesday, December 7, 2021 10:35
> > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > Subject: Re: [squeak-dev] Default preferences
> > >
> > > My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?
> > >
> > > Best,
> > > Marcel
> > > Am 07.12.2021 10:33:32 schrieb Marcel Taeumel :
> > > Hi Jaromir --
> > >
> > > > E.g. try do-it (a few times):
> > >
> > > Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.
> > >
> > > Best,
> > > Marcel
> > > Am 07.12.2021 10:01:48 schrieb mail at jaromir.net :
> > > Hi all --
> > > >
> > > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > > >
> > > > Best,
> > > > Marcel
> > > I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):
> > >
> > > self halt. self halt
> > >
> > > The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)
> > >
> > > Best,
> > >
> > > ~~~
> > > ^[^ Jaromir
> > >
> > > Sent from Squeak Inbox Talk
> > >
> > > On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:
> > >
> > > > Hi all --
> > > >
> > > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > > >
> > > > Best,
> > > > Marcel
> > > > Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> > > > >> 1. Windowing
> > > > >> Personally, the first thing I do in every new image is to enable these prefs:
> > > > >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> > > > >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
> > > >
> > > > Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
> > > >
> > > > > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
> > > >
> > > > But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
> > > >
> > > >
> > > > >> 4. Editing
> > > > >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> > > > >> - Enclose selection with brackets -> true
> > > >
> > > > Again, very not OK for me.
> > > >
> > > > tim
> > > > --
> > > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > > > Hackers have kernel knowledge.
> > > >
> > > >
> > > >
> > > > 

...

(2) what is CMD-s supposed to do in the Transcript window?

I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing

That's perfectly fine with me. Way better than dispappear everything :D Thanks ...Once I had some commented results in Transcript I wanted to copy and hit CMD-s by mistake... can't forget the shock :)

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-27T10:57:35-08:00, tim@rowledge.org wrote:

...

On 2021-12-26, at 11:41 PM, mail at jaromir.net wrote:

(2) what is CMD-s supposed to do in the Transcript window?

I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Non curo. Si metrum non habet, non est poema = I don't care. If it doesn't rhyme, it isn't a poem.

Hi Jaromir --

would it be difficult/reasonable to transform the button to Done instead of just greying out?

The user can finish the configuration on either page. It is not necessary to click through all pages. Maybe one just wants to set the UI theme and be done with it. Also, I don't want the user to click on "Done" by accident, so I placed it in the lower right corner, which I think is common in Western GUI dialogs. The wizard is mainly for the initial Squeak experience where the world is not full screen but in a window. Sorry for any inconveniences on your wide-screen monitor with Squeak being in full-screen mode. ... I don't think the issues you described warrant the changes you suggested. :-/

And I really want the users to try out the settings in the live windows. So, I want the user to have to look across those windows to find the "Done" button. :-D The other preferences browser might be more stream-lined for your purposes.

Best, Marcel Am 12.01.2022 13:56:36 schrieb mail@jaromir.net mail@jaromir.net: Hi Marcel,

just an idea: in the Wizard you proceed back and forth via the Next and Previous buttons; when you get to the last (6th) the Next button greys out to indicate the end; on an ultra wide screen the Done button is all the way across to the right, sort of out of sight; would it be difficult/reasonable to transform the button to Done instead of just greying out? (While keeping Done as is for a fast way out, indeed)

Thanks,

best, ~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-27T20:00:12+01:00, mail@jaromir.net wrote:

...

...

(2) what is CMD-s supposed to do in the Transcript window?

I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing

That's perfectly fine with me. Way better than dispappear everything :D Thanks ...Once I had some commented results in Transcript I wanted to copy and hit CMD-s by mistake... can't forget the shock :)

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-27T10:57:35-08:00, tim at rowledge.org wrote:

>
>
> > On 2021-12-26, at 11:41 PM, mail at jaromir.net wrote:
> >
> > (2) what is CMD-s supposed to do in the Transcript window?
> I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Non curo. Si metrum non habet, non est poema = I don't care. If it doesn't rhyme, it isn't a poem.
>
>

Hi Jaromir --

I've noticed you added almost half of them to the Extras menu

When we introduced UI themes in Squeak 5.1, I noticed several preferences that are tightly coupled to such themes. It felt important enough to be able the change theme through the "Extras" menu ... maybe along with those coupled other UI-related preferences. Now, the "scale factor" went into the extra's menu, too.

Those interaction-related preferences are not in the "Extras" menu but in the wizard. It was based on a gut feeling.

Tempted to ask why not all ;)

Because those three different "tools" around preferences have different use cases:

- Apps > "Preference Wizard" ... is for the first contact and for avoiding too exhausting discussions about default preferences ... - Extras > "Themes & Colors" / "Scale Factor" ... is for occasional demos or display switching - Tools > "Preferences" ... is for everything (else)

Well .. World > Appearance is almost obsolete these days ...

Best, Marcel Am 12.01.2022 14:19:55 schrieb mail@jaromir.net mail@jaromir.net: Hi Marcel, Yes, the "accident" argument crossed my mind too; sorry for the noise :) When I try the various preferences I return to the Wizard quite often; I've noticed you added almost half of them to the Extras menu - that's perfect, such a convenient access! Tempted to ask why not all ;) Thanks,

best, ~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2022-01-12T14:10:39+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

...

would it be difficult/reasonable to transform the button to Done instead of just greying out?

The user can finish the configuration on either page. It is not necessary to click through all pages. Maybe one just wants to set the UI theme and be done with it. Also, I don't want the user to click on "Done" by accident, so I placed it in the lower right corner, which I think is common in Western GUI dialogs. The wizard is mainly for the initial Squeak experience where the world is not full screen but in a window. Sorry for any inconveniences on your wide-screen monitor with Squeak being in full-screen mode. ... I don't think the issues you described warrant the changes you suggested. :-/

And I really want the users to try out the settings in the live windows. So, I want the user to have to look across those windows to find the "Done" button. :-D The other preferences browser might be more stream-lined for your purposes.

Best, Marcel Am 12.01.2022 13:56:36 schrieb mail at jaromir.net : Hi Marcel,

just an idea: in the Wizard you proceed back and forth via the Next and Previous buttons; when you get to the last (6th) the Next button greys out to indicate the end; on an ultra wide screen the Done button is all the way across to the right, sort of out of sight; would it be difficult/reasonable to transform the button to Done instead of just greying out? (While keeping Done as is for a fast way out, indeed)

Thanks,

best,

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-27T20:00:12+01:00, mail at jaromir.net wrote:

> > > (2) what is CMD-s supposed to do in the Transcript window?
> > I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing
> >
> That's perfectly fine with me. Way better than dispappear everything :D Thanks
> ...Once I had some commented results in Transcript I wanted to copy and hit CMD-s by mistake... can't forget the shock :)
>
> ~~~
> ^[^ Jaromir
>
> Sent from Squeak Inbox Talk
>
> On 2021-12-27T10:57:35-08:00, tim at rowledge.org wrote:
>
> >
> >
> > > On 2021-12-26, at 11:41 PM, mail at jaromir.net wrote:
> > >
> > > (2) what is CMD-s supposed to do in the Transcript window?
> > I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Useful Latin Phrases:- Non curo. Si metrum non habet, non est poema = I don't care. If it doesn't rhyme, it isn't a poem.
> >
> >
>
>

Hi Marcel, hi all,

let me take another attempt on this amazing comprehensive debate. :-)

#1 Presets

Don't get me started on a "Novice Mode". There is even research on why this is not a good idea. Only "novices" and "experts". Only two bins. Sure.

I would be interested in reading more details about this. :-) Could you give me a pointer to any publication?

Specifically, I wonder whether a "novice mode" has been revealed as impractical or whether it was the general concept of "preference presets". I'm imagining a single button in the preference wizard "I'm feeling lucky" / "I'm open to change" that interested users could click to get the full charge of "Squeak's unorthodox features". Conversative users (this should not sound degrading) can ignore this button and people who try out Squeak just because they are looking for a different experience could give it a try and maybe toggle back again. This preset should only include a few prefs in the wizard to maintain explorability and reduce confusion. What would you think about that? :-)

I also would like to support this quote by Stef:

An idea would be to make customized images of different 'styles' available (and advertized) on the site, with an explicit in-your-face statement about the flexibility of Squeak.

***

#2 Preference "Always open tools attached to cursor"

Moved to a new thread, for the sake of clarity. :-)

***

#3 Updated list of proposals for changed default preference values

I have revised and split up my original list of proposals based on your feedback. Please discuss (or just agree :P) the following:

A. "Default defaults":

These are mostly "lost feature flags" which enhance the UX and add nearly zero harm IMHO:

2. Tools - Show annotation pane in the debugger -> true - Extra debugger buttons -> true - Show stack variables in debugger -> maybe? I like it, does it harm? - Stack Size in Notifier/Full Debugger -> increase by factor 2 or more, should not be a performance issue nowadays, but increases convenience

3. Morphs - Wrapped tree navigation -> true (just consistent to lists) - Use the new color-picker -> true (c'mon, this tool is already >11 years old! :p)

B. "I'm feeling lucky" preset (if we decide on introducing one):

1. Windowing "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".

Looking forward to your replies!

Best, Christoph

PS: Does anyone use flaps any longer or should we hide them by default? :-)

--- Sent from Squeak Inbox Talk

On 2022-01-12T14:50:12+01:00, mail@jaromir.net wrote:

Hi Marcel,

thanks again for your explanation.

...

Because those three different "tools" around preferences have different use cases:

• Extras > "Themes & Colors" / "Scale Factor" ... is for occasional demos or display switching

I've never thought about it this way... thanks!

...

Well .. World > Appearance is almost obsolete these days ...

Yep, feels inconsistent...

best,

^[^    Jaromir

Sent from Squeak Inbox Talk

On 2022-01-12T14:27:42+01:00, marcel.taeumel at hpi.de wrote:

> Hi Jaromir --
> 
> > I've noticed you added almost half of them to the Extras menu
> 
> When we introduced UI themes in Squeak 5.1, I noticed several preferences that are tightly coupled to such themes. It felt important enough to be able the change theme through the "Extras" menu ... maybe along with those coupled other UI-related preferences. Now, the "scale factor" went into the extra's menu, too.
> 
> Those interaction-related preferences are not in the "Extras" menu but in the wizard. It was based on a gut feeling.
> 
> > Tempted to ask why not all ;)
> 
> Because those three different "tools" around preferences have different use cases:
> 
> - Apps > "Preference Wizard" ... is for the first contact and for avoiding too exhausting discussions about default preferences ...
> - Extras > "Themes & Colors" / "Scale Factor" ... is for occasional demos or display switching
> - Tools > "Preferences" ... is for everything (else)
> 
> Well .. World > Appearance is almost obsolete these days ...
> 
> Best,
> Marcel
> Am 12.01.2022 14:19:55 schrieb mail at jaromir.net <mail at jaromir.net>:
> Hi Marcel,
> Yes, the "accident" argument crossed my mind too; sorry for the noise :) When I try the various preferences I return to the Wizard quite often; I've noticed you added almost half of them to the Extras menu - that's perfect, such a convenient access! Tempted to ask why not all ;)
> Thanks,
> 
> best,
> ~~~
> ^[^ Jaromir
> 
> Sent from Squeak Inbox Talk
> 
> On 2022-01-12T14:10:39+01:00, marcel.taeumel at hpi.de wrote:
> 
> > Hi Jaromir --
> >
> > > would it be difficult/reasonable to transform the button to Done instead of just greying out?
> >
> > The user can finish the configuration on either page. It is not necessary to click through all pages. Maybe one just wants to set the UI theme and be done with it. Also, I don't want the user to click on "Done" by accident, so I placed it in the lower right corner, which I think is common in Western GUI dialogs. The wizard is mainly for the initial Squeak experience where the world is not full screen but in a window. Sorry for any inconveniences on your wide-screen monitor with Squeak being in full-screen mode. ... I don't think the issues you described warrant the changes you suggested. :-/
> >
> > And I really want the users to try out the settings in the live windows. So, I want the user to have to look across those windows to find the "Done" button. :-D The other preferences browser might be more stream-lined for your purposes.
> >
> > Best,
> > Marcel
> > Am 12.01.2022 13:56:36 schrieb mail at jaromir.net :
> > Hi Marcel,
> >
> > just an idea: in the Wizard you proceed back and forth via the Next and Previous buttons; when you get to the last (6th) the Next button greys out to indicate the end; on an ultra wide screen the Done button is all the way across to the right, sort of out of sight; would it be difficult/reasonable to transform the button to Done instead of just greying out? (While keeping Done as is for a fast way out, indeed)
> >
> > Thanks,
> >
> > best,
> > ~~~
> > ^[^ Jaromir
> >
> > Sent from Squeak Inbox Talk
> >
> > On 2021-12-27T20:00:12+01:00, mail at jaromir.net wrote:
> >
> > > > > (2) what is CMD-s supposed to do in the Transcript window?
> > > > I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing
> > > >
> > > That's perfectly fine with me. Way better than dispappear everything :D Thanks
> > > ...Once I had some commented results in Transcript I wanted to copy and hit CMD-s by mistake... can't forget the shock :)
> > >
> > > ~~~
> > > ^[^ Jaromir
> > >
> > > Sent from Squeak Inbox Talk
> > >
> > > On 2021-12-27T10:57:35-08:00, tim at rowledge.org wrote:
> > >
> > > >
> > > >
> > > > > On 2021-12-26, at 11:41 PM, mail at jaromir.net wrote:
> > > > >
> > > > > (2) what is CMD-s supposed to do in the Transcript window?
> > > > I don't think I've ever in 40 years thought to try saving the Transcript. I would suggest it should do nothing
> > > >
> > > > tim
> > > > --
> > > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > > > Useful Latin Phrases:- Non curo. Si metrum non habet, non est poema = I don't care. If it doesn't rhyme, it isn't a poem.
> > > >
> > > >
> > >
> > >
> > 

Hi Marcel, hi all,

Well, I play the piano with both hands.

Me too. Still, I would love an alwaysAttach option. :P

Consequently, there are different groups of users.

Now we're talking! :-) There at least three persons by now (including me) who have reported that they would like such a feature. What problem do you expect from giving them a preference to realize this dream, which would come with an expected added CYCLO of 1 or 2 only? :-)

Until now, Squeak's keyboard-only support is rather sketchy. We should work on that.

That will be a useful goal, too, but a) don't let the perfect be the enemy of the good, and b) as a mouse-attracted user, I would not like the system or its designers re-educate me and imposing new habits to me. :-)

Jaromir:

In such case I'd expect if I start a tool from the keyboard and continue with the keyboard (press an arrow e.g.) the windows 'dis-attaches' from the mouse silently and stays in its current position

Hm, I thought about this, but I am not sure. It's also a nice gesture to do the following: Cmd + P (preference browser, attaches to cursor), type a search term "workspace", and finish your mouse gesture, where you can drag the attached window to a useful size that matches the individual contents of the now-filled window. Can you reproduce that? :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2021-12-27T08:41:14+01:00, mail@jaromir.net wrote:

Hi Marcel, Christoph and all,

a few more notes about preferences:

(1) sortMessageCategoriesAlphabetically - my suggestion would be to place starred *extensions categories behind "normal" categories; alphabetical ordering places them all before 'accessing' etc. In case of Object for example the list starts with *Deprecated and you scroll over a lot of extension categories before you get down to "normal" categories.

(2) what is CMD-s supposed to do in the Transcript window? Currently it clears the window without a way back - undo (CMD-z) doesn't restore it. CMD-l (lowercase L) also clears the Transcript but the undo works... Help's Keyboard Shortcuts doesn't help: CMD-s is supposed to "save" (I understand diffent windows have different sets of shortcuts but Help's Keyboard Shortcuts is the only info I have - or any beginner). Why not e.g. save Transcript's window contents similarly as Workspace's contents on Accept/Save/CMD-s or make it a preference?

(3) about the "always attach to cursor" mode suggested by Christoph earlier - because currently there's no strong support of keyboard only interaction, why not make it a preference: attach on mouse events / attach always? I still find the current 'attach on mouse events' mode confusing; I don't explicitely think how I start a tool, whether using a key or the mouse, you don't even have a choce always... so my brain often expects the tool under the cursor and it shows up somewhere else :)

(4) regarding the relative position of the tool being attached and the cursor - an offset of 25% would be better than 20% because in case of a debugger notifier window the 20% offset places the cursor over the Proceed button ;)

Thanks,

^[^    Jaromir

Sent from Squeak Inbox Talk

On 2021-12-10T10:39:34+01:00, marcel.taeumel at hpi.de wrote:

> Hi Jaromir --
> 
> Agreed. I am looking a better place to implement that 20% offset. The centered pop-up did already confuse me at times, too.
> 
> Other opinions about this?
> 
> Best,
> Marcel
> Am 10.12.2021 10:30:32 schrieb mail at jaromir.net <mail at jaromir.net>:
> Hi Marcel,
> 
> > Hi Jaromir --
> >
> > > I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient
> >
> > Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?
> >
> 
> The main reason I find it more convenient (or just less distracting) is when I open a window by clicking on a button or from the context menu near the top of the screen (or the left side) the attached window is partly outside my screen. Lower right would be even worse in this regard :) And upper left is dangerously close to the close button. But as I said, it's a small inconvenience for me and maybe even just me :)
> 
> > (And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)
> 
> I won't dispute this :D I just used this place to test the offset ;)
> 
> Thanks,
> ~~~
> ^[^ Jaromir
> 
> Sent from Squeak Inbox Talk
> 
> On 2021-12-10T10:14:29+01:00, marcel.taeumel at hpi.de wrote:
> 
> > Hi Jaromir --
> >
> > > I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient
> >
> > Any idea, why? :-) From the users perspective, you have to first look at the upper left corner (to position) and then at the lower right corner (to resize). Ideally, we would even position the mouse cursor at exactly those two locations. The center is a trade-off. How would 20% offset help?
> >
> > (And HandMorph >> #attachMorph: is definitely the wrong place to make such a change because it is very generic but your request very specific. #attachMorph: is used about 100 times across the image, each with its own use case.)
> >
> > Best,
> > Marcel
> > Am 09.12.2021 20:25:31 schrieb mail at jaromir.net :
> > Hi Christoph, all,
> >
> > A small suggestion - current implementation attaches the new window centered around the cursor - I personally find placing it asymetrically with the cursor near the upper left corner (e.g. 20% offset) more convenient; Here's the change:
> >
> > attachMorph: m
> > "Position the center of the given morph under this hand, then grab it.
> > This method is used to grab far away or newly created morphs."
> > | delta |
> > self releaseMouseFocus. "Break focus"
> > self showTemporaryCursor: nil.
> > delta := m bounds extent // 5.
> > m position: (self position - delta).
> > m formerPosition: m position.
> > targetOffset := m position - self position.
> > self addMorphBack: m.
> >
> >
> > ~~~
> > ^[^ Jaromir
> >
> > Sent from Squeak Inbox Talk
> >
> > On 2021-12-07T21:30:09+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> >
> > > Hi Jaromir,
> > >
> > >
> > > > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
> > >
> > > Sounds wrong to me, nice catch! We should look into this.
> > >
> > >
> > > Independently of this bug, I have one more general question for you: Does it appear rather intuitive or rather confusing for you how this preference is intended to work? Its intention is: if and only if the previous input operation was made via mouse, open the tool attached to the mouse cursor. This is meant to support users to keep with their current input device - if I was using the keyboard before, don't force me to use the mouse.
> > >
> > > We had some internal discussions recently about this mode because I and someone else was actually preferring an "always attach to cursor" mode, which felt more intuitive to us. To you as someone who might be not yet as routine-blinded as us, what sounds more intuitive to you?
> > >
> > > If you would like to try out the alternative mode, you could comment out the "and: [ | event | event := self currentEvent. event isMouse and: [event isMouseUp]]" send in SystemWindow >> #openAsTool by true. Looking forward to hearing your impressions! :-)
> > >
> > >
> > > > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
> > >
> > >
> > > This would be very welcome! We should also unify the Uppercase/lowercase of all categories.
> > >
> > >
> > > Best,
> > >
> > > Christoph
> > >
> > >
> > > ________________________________
> > > Von: Squeak-dev im Auftrag von mail at jaromir.net
> > > Gesendet: Dienstag, 7. Dezember 2021 18:41 Uhr
> > > An: squeak-dev at lists.squeakfoundation.org; Taeumel, Marcel
> > > Betreff: Re: [squeak-dev] Default preferences
> > >
> > > Hi Marcel,
> > >
> > > >
> > > > >No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > >
> > > > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> > >
> > > Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:
> > >
> > > self halt. self halt. self halt
> > >
> > > and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??
> > >
> > > Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.
> > >
> > > This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)
> > >
> > > I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)
> > >
> > > Apologies for such a long message.
> > >
> > > Thanks a lot,
> > >
> > > PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?
> > >
> > > ~~~
> > > ^[^ Jaromir
> > >
> > > Sent from Squeak Inbox Talk
> > >
> > > On 2021-12-07T12:21:45+01:00, marcel.taeumel at hpi.de wrote:
> > >
> > > > Hi Jaromir --
> > > >
> > > > >No ? when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > >
> > > > Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.
> > > >
> > > > Best,
> > > > Marcel
> > > > Am 07.12.2021 11:56:45 schrieb Jaromir Matas :
> > > > Checked already ?
> > > > Yes ? improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent
> > > > No ? when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)
> > > > Thanks!
> > > >
> > > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > > Sent: Tuesday, December 7, 2021 11:52
> > > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > > Subject: Re: [squeak-dev] Default preferences
> > > >
> > > > Hi Jaromir --
> > > >
> > > > Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)
> > > >
> > > > Best,
> > > > Marcel
> > > > Am 07.12.2021 11:05:36 schrieb Jaromir Matas :
> > > > I?ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.
> > > >
> > > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > > Sent: Tuesday, December 7, 2021 10:59
> > > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > > Subject: Re: [squeak-dev] Default preferences
> > > >
> > > > Hi Jaromir --
> > > >
> > > > Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?
> > > >
> > > > > I think it happened with some dialogues as well but can?t remember now.
> > > >
> > > > Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)
> > > >
> > > > Best,
> > > > Marcel
> > > > Am 07.12.2021 10:48:58 schrieb Jaromir Matas :
> > > > Hi Marcel,
> > > > I tried both do-it from the menu and via CTRL-d and they both behave erratically.
> > > >
> > > > I?m not sure it?s only the Debugger; I think it happened with some dialogues as well but can?t remember now.
> > > > Thanks,
> > > > Jaromir
> > > >
> > > > From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
> > > > Sent: Tuesday, December 7, 2021 10:35
> > > > To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
> > > > Subject: Re: [squeak-dev] Default preferences
> > > >
> > > > My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?
> > > >
> > > > Best,
> > > > Marcel
> > > > Am 07.12.2021 10:33:32 schrieb Marcel Taeumel :
> > > > Hi Jaromir --
> > > >
> > > > > E.g. try do-it (a few times):
> > > >
> > > > Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.
> > > >
> > > > Best,
> > > > Marcel
> > > > Am 07.12.2021 10:01:48 schrieb mail at jaromir.net :
> > > > Hi all --
> > > > >
> > > > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):
> > > >
> > > > self halt. self halt
> > > >
> > > > The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)
> > > >
> > > > Best,
> > > >
> > > > ~~~
> > > > ^[^ Jaromir
> > > >
> > > > Sent from Squeak Inbox Talk
> > > >
> > > > On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:
> > > >
> > > > > Hi all --
> > > > >
> > > > > There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
> > > > >
> > > > > Best,
> > > > > Marcel
> > > > > Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> > > > > >> 1. Windowing
> > > > > >> Personally, the first thing I do in every new image is to enable these prefs:
> > > > > >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> > > > > >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
> > > > >
> > > > > Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
> > > > >
> > > > > > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
> > > > >
> > > > > But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
> > > > >
> > > > >
> > > > > >> 4. Editing
> > > > > >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> > > > > >> - Enclose selection with brackets -> true
> > > > >
> > > > > Again, very not OK for me.
> > > > >
> > > > > tim
> > > > > --
> > > > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > > > > Hackers have kernel knowledge.
> > > > >
> > > > >
> > > > >
> > > > > 

I would be in favour of this approach too; I quite like the open-attached stuff but the way it works with notifiers is decidedly sub-optimal

On 2022-02-08, at 2:51 AM, mail@jaromir.net wrote:

The only thing that drives me crazy is positioning the debugger notifier window - it's only purpose is to start debugging or close/proceed so positioning brings no benefit. How about to treat a few exceptions like Debugger Notifier differently - not attached?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 6) "Our competitors are without honor!"

Hi Christoph --

Still -1

However, we could make the current preference the default implementation -- which mimics the old MVC days anyway -- and then change the effect of the current preference to not check the interaction method. Then we would not need another preference for this.

Tim? Eliot? Dave? You all remember that place-and-resize interaction from any new window that wants to pop-up in MVC, right?

Maybe give it a shot. If there is too much resistance before the release, we can reconsider.

Best, Marcel Am 01.04.2022 16:09:07 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi all,

thanks for the feedback. Based on your responses, I have uploaded the changeset openToolsInHandStrategy.1.cs to the list right now. It gives you a new preference open all tools attached to the hand, regardless of the former interaction mode. Please try it out and give feedback! :-)

Best, Christoph

--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]

On 2022-02-08T10:11:15-08:00, tim@rowledge.org wrote:

I would be in favour of this approach too; I quite like the open-attached stuff but the way it works with notifiers is decidedly sub-optimal

...

On 2022-02-08, at 2:51 AM, mail at jaromir.net wrote:

The only thing that drives me crazy is positioning the debugger notifier window - it's only purpose is to start debugging or close/proceed so positioning brings no benefit. How about to treat a few exceptions like Debugger Notifier differently - not attached?

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 6) "Our competitors are without honor!"

Hi Marcel,

I’m not saying you should fix it or anything or that it’s important, just reporting :) I’ve just downloaded a fresh image (20816) turned on the “attach tools to mouse…” via Wizard, opened Workspace, pasted the example (self halt. self halt. self error) and run it from the keyboard – for CTRL-d, CTRL-p, CTRL-i or CTRL-I clicking Proceed works one way and for CTRL-D the other way.

Best, Jaormir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Wednesday, December 8, 2021 9:17 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

[..] and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Sorry. Works for me. Both CTRL+d and CTRL+D. I cannot reproduce that bug in recent Trunk. :-/

Best, Marcel

Am 07.12.2021 19:01:19 schrieb mail@jaromir.net mail@jaromir.net: Hi Marcel,

...

No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:

self halt. self halt. self halt

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.

This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)

I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)

Apologies for such a long message.

Thanks a lot,

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T12:21:45+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

...

No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Best, Marcel Am 07.12.2021 11:56:45 schrieb Jaromir Matas : Checked already 😊 Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic) Thanks!

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 11:52 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)

Best, Marcel Am 07.12.2021 11:05:36 schrieb Jaromir Matas : I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:59 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

...

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)

Best, Marcel Am 07.12.2021 10:48:58 schrieb Jaromir Matas : Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:35 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel Am 07.12.2021 10:33:32 schrieb Marcel Taeumel : Hi Jaromir --

...

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel Am 07.12.2021 10:01:48 schrieb mail at jaromir.net : Hi all --

...

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:

> Hi all --
>
> There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
>
> Best,
> Marcel
> Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> >> 1. Windowing
> >> Personally, the first thing I do in every new image is to enable these prefs:
> >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
>
> Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
>
> > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
>
> But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
>
>
> >> 4. Editing
> >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> >> - Enclose selection with brackets -> true
>
> Again, very not OK for me.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Hackers have kernel knowledge.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
>







-------------- next part --------------
An HTML attachment was scrubbed...
URL:

I’ve realized there is a difference between the two scenarios: CTRL-d, CTRL-p, CTRL-i or CTRL-I run the example and actually it’s the system, not me, opens the debugger …while in the CTRL-D scenario it’s me directly who opens the Debugger. From a user perspective the difference is not much visible and maybe shouldn’t even matter…? Thanks, Jaromir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Wednesday, December 8, 2021 9:58 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

I did not reproduce your example correctly. I do now understand, what you mean. I am looking into it.

Best, Marcel

Am 08.12.2021 09:51:19 schrieb Jaromir Matas mail@jaromir.net: Hi Marcel,

I’m not saying you should fix it or anything or that it’s important, just reporting :) I’ve just downloaded a fresh image (20816) turned on the “attach tools to mouse…” via Wizard, opened Workspace, pasted the example (self halt. self halt. self error) and run it from the keyboard – for CTRL-d, CTRL-p, CTRL-i or CTRL-I clicking Proceed works one way and for CTRL-D the other way.

Best, Jaormir

From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Wednesday, December 8, 2021 9:17 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

[..] and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Sorry. Works for me. Both CTRL+d and CTRL+D. I cannot reproduce that bug in recent Trunk. :-/

Best, Marcel

Am 07.12.2021 19:01:19 schrieb mail@jaromir.net mail@jaromir.net: Hi Marcel,

...

No - when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Yes, this is exactly what I'd expect but is not happening (or I'm still missing something) - if you take the example:

self halt. self halt. self halt

and run it from the keyboard via CTRL-d it correctly opens a Debugger NOT attached then clicking Proceed opens the next Debugger again NOT attached etc. - is this right??

Because: if you run the same example from the keyboard via CTRL-D it opens the first Debugger not attached BUT after clicking Proceed it opens the next Debugger window ATTACHED and after clicking Proceed the next one is again attached etc.

This inconsistency confuses me; I very often start evaluation by CTRL-d or CTRL-D :)

I'd expect the Debugger's the behavior after clicking Proceed should be consistent regardless whether I initiated the evaluation from the keyboard via CTRL-d or CTRL-D. I.e. either clicking Proceed should always attach the next Debugger window or never... (I'd personally prefer if the small/simple Debugger windows always opened NOT attached)

Apologies for such a long message.

Thanks a lot,

PS: There are two "tools" groups in the preference browser, one called "Tools "and the other one "tools" - is it intentional?

~~~ ^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-07T12:21:45+01:00, marcel.taeumel@hpi.de wrote:

Hi Jaromir --

...

No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic)

Well, please read the preference's description again. Only mouse interaction is affected. So, the behavior you describe is exactly as intended. We do not want to force the use into a bi-manual interaction style if they try to primarily use the keyboard.

Best, Marcel Am 07.12.2021 11:56:45 schrieb Jaromir Matas : Checked already 😊 Yes – improved for do-it via CTRL-d: now all invocations when pressing Proceed go not attached to the mouse -> consistent No – when I run the example via CTRL-SHIFT-d (start the Debugger on it) the Debugger opens not attached but the subsequent Debugger(s) when hitting Proceed start attached -> inconsistent (but not erratic) Thanks!

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 11:52 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Please check whether Morphic-mt.1816 (Trunk) improves the situation. :-)

Best, Marcel Am 07.12.2021 11:05:36 schrieb Jaromir Matas : I’ve just tested the likelihood: the first CTRL-d opens the Debugger not attached and then pressing Proceed has almost 50% chance to either open attached to the mouse or not attached.

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:59 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

Hi Jaromir --

Yes, there are some cases where the mouse interaction does not lead to the tool being attached. No, I am not aware of a situation where a keyboard interaction does that. What's your feeling? Does it work like 95% of the time?

...

I think it happened with some dialogues as well but can’t remember now.

Dialog windows should never attach to the mouse cursor. See SystemWindow >> #openAsTool to better understand the mechanics of that preference. It relies on the dynamically scoped #currentEvent, which is not bullet proof. :-)

Best, Marcel Am 07.12.2021 10:48:58 schrieb Jaromir Matas : Hi Marcel, I tried both do-it from the menu and via CTRL-d and they both behave erratically.

I’m not sure it’s only the Debugger; I think it happened with some dialogues as well but can’t remember now. Thanks, Jaromir

From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de] Sent: Tuesday, December 7, 2021 10:35 To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org] Subject: Re: [squeak-dev] Default preferences

My bad. You did a "do it", right? Hmm... seems to be debugger-related. Other tools are fine, right? Like "String browse"?

Best, Marcel Am 07.12.2021 10:33:32 schrieb Marcel Taeumel : Hi Jaromir --

...

E.g. try do-it (a few times):

Works for me. Did you "debug it" via the context menu using the mouse? It should only attach if the interaction was done with the mouse so that users can retain focus on the cursor position. Keyboard interaction should not be affected.

Best, Marcel Am 07.12.2021 10:01:48 schrieb mail at jaromir.net : Hi all --

...

There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.

Best, Marcel

I've been testing the "open tools attached to mouse cursor" preference on but its behavior is erratic. E.g. try do-it (a few times):

self halt. self halt

The Debugger sometimes opens attached to the mouse and sometimes not... It's so irregular I haven't discovered any pattern in the behavior and eventually switched the preference off. Is it happening to you too? (I had clean images and Win10 environment)

Best,

^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de wrote:

> Hi all --
>
> There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
>
> Best,
> Marcel
> Am 23.11.2021 00:13:44 schrieb tim Rowledge :
> >> 1. Windowing
> >> Personally, the first thing I do in every new image is to enable these prefs:
> >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
>
> Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
>
> > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
>
> But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
>
>
> >> 4. Editing
> >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> >> - Enclose selection with brackets -> true
>
> Again, very not OK for me.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Hackers have kernel knowledge.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
>







-------------- next part --------------
An HTML attachment was scrubbed...
URL:

Hi all,

thanks for the feedback!

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

This would have been pretty much my thought; the use of Transcript is just one out of many possible applications for a workspace. And personally, I do also favor the MDI style over SDI. :-)

Best, Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Dienstag, 23. November 2021 00:13:33 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Default preferences

...

1. Windowing

Personally, the first thing I do in every new image is to enable these prefs: "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active". Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?

Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.

For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)

But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.

...

4. Editing

• Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
• Enclose selection with brackets -> true

Again, very not OK for me.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Hackers have kernel knowledge.