Hi Christoph,

please make sure to honor the SystemWindow reuseWindows preference when

revising this behavior. :-)

I also noticed what appeared to be a slight regression with this when the MessageTrace was spawned by the (I)nheritance function, and then again from the same method in the just-spawned MessageTrace. It spawns another, duplicate, MessageTrace. After that, however, no more are spawned by doing the same behavior. Very strange!

I traced the cause to this line of code (see attached fileout). Marcel made this logic change when he also introduced the "context" and "requestor" complexities into the method. The compact comment there says, "Search for the requesting window to ignore it later.".

After fixing the squeak source server, revisions is working again and I found the good comment Marcel made about the change (even though I disagree with it). ________ Name: Morphic-mt.1761 Author: mt Time: 26 April 2021, 9:45:48.321064 am UUID: b6da97e8-f5a5-ac41-9880-5a0c0e547913 Ancestors: Morphic-mt.1760

Avoid reusing a window if it is the requesting window. This is useful for the "browse" button in the system browser or even for the "hierarchy" button in the hierarchy browser if the hierarchy is the same. A common yet simple way to duplicate a window without using a halo. Since this is an explicit user interaction, it is not expected to interfere with the "re-use windows" preference. I suppose. :-) _________

So, I actually rely on Reuse Windows to *top* the requestor window (I always use the, "Windows' Contents Are Always Active" mode) if it's the only one, because the point of Reuse Windows is to not have to _know_ whether that's the only one open, and therefore avoiding opening a duplicate. Avoiding unwanted duplicates is actually the purpose of Reuse Windows. And if the users' goal is explicitly to make a duplicate, then don't understand why the duplicate halo, even despite being at another user-interface level, should be an issue. What's wrong with using Squeak's power? And even still another way is to simply make it dirty on purpose. So, I'm not a big fan of this change.

Best, Chris

Hi Chris --

I have an idea on how to fix this regression again. Stay tuned. :-)

Best, Marcel Am 10.01.2022 11:17:39 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Chris --

Aha. Well, these TextEditor changes are obviously in no direct relationship with the MessageTrace tool. An indirection through the model instead a global call to #systemNavigation are *always* favorable since more expressive and configurable. A custom model such as MessageTrace should be able to easily provide the desired behavior.

You inbox suggestions via Morphic-cmm.1838 and 1839 are therefore not acceptable. I will try to solve this issue in MessageTrace directly.

Best, Marcel

P.S.: Your definition of "execution flow" is somewhat brittle since there are is no dynamic trace data involved. You rely on static analysis only. :-) Am 10.01.2022 01:41:17 schrieb Chris Muller asqueaker@gmail.com: Hi Marcel,

I'm doing some testing in trunk and just noticed this.  When selecting a message in the code pane and browsing senders, **it must always spawn a new MessageTrace** instead of mangling the to the list at the top.

The trace at the top is supposed to represent execution flow between the messages in the list, and NOT different random messages that derail the trace and make it a complete mess.

I also noticed this has been backported to 5.3.

- Chris

On Mon, Apr 27, 2020 at 2:32 AM <commits@source.squeak.org [mailto:commits@source.squeak.org]> wrote:

Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1652.mcz [http://source.squeak.org/trunk/Morphic-mt.1652.mcz]

==================== Summary ====================

Name: Morphic-mt.1652 Author: mt Time: 27 April 2020, 9:31:57.493264 am UUID: d23bbde5-4e42-3547-960d-39994fc21f56 Ancestors: Morphic-ct.1651

Fixes regression #browseIt in TraceMessages, too. Now all recent hick-ups with TraceMessages are gone. There are still some hooks missing such as #browseAllAccessTo:from:.

However, I think we should push down those backstops from Object to Model.

Note that I already backported this fix to Squeak 5.3.

=============== Diff against Morphic-ct.1651 ===============

Item was changed:   ----- Method: TextEditor>>browseIt (in category 'menu messages') -----   browseIt         "Launch a browser for the current selection, if appropriate."

Preferences alternativeBrowseIt ifTrue: [^ self browseClassFromIt].

self lineSelectAndEmptyCheck: [^ morph flash].

"First, try to show all accesses to instance or class variables."         self selectedInstanceVariable ifNotNil:                 [:nameToClass | self systemNavigation                         browseAllAccessesTo: nameToClass key                         from: nameToClass value].         self selectedClassVariable ifNotNil: +               [:binding | self model browseAllCallsOn: binding]. -               [:binding | self systemNavigation browseAllCallsOn: binding].

"Then, either browse the class (from a binding) or all implementors of a selector."         self selectedBinding ifNotNil:                 [:binding | ^ self systemNavigation browseClass: binding].         self selectedSelector ifNotNil: +               [:selector | ^ self model browseAllImplementorsOf: selector]. -               [:selector | ^ self systemNavigation browseAllImplementorsOf: selector].

morph flash!

Thanks!

Will test later tonight.

On Tue, Jan 11, 2022 at 3:00 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi Chris --

Done. Regression fixed. See Tools-mt.1101 and Morphic-mt.1844 in Trunk. Please report back any issues with that.

Feel free to revert the backported change in 5.3 (TextEditor) if you think it's better. I need to focus on 6.0 for now. :-) I will move Morphic-cmm.1839 from Inbox to Treated.

Best, Marcel

Am 10.01.2022 16:33:52 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Chris --

I have an idea on how to fix this regression again. Stay tuned. :-)

Best, Marcel

Am 10.01.2022 11:17:39 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Chris --

Aha. Well, these TextEditor changes are obviously in no direct relationship with the MessageTrace tool. An indirection through the model instead a global call to #systemNavigation are *always* favorable since more expressive and configurable. A custom model such as MessageTrace should be able to easily provide the desired behavior.

You inbox suggestions via Morphic-cmm.1838 and 1839 are therefore not acceptable. I will try to solve this issue in MessageTrace directly.

Best, Marcel

P.S.: Your definition of "execution flow" is somewhat brittle since there are is no dynamic trace data involved. You rely on static analysis only. :-)

Am 10.01.2022 01:41:17 schrieb Chris Muller asqueaker@gmail.com: Hi Marcel,

I'm doing some testing in trunk and just noticed this. When selecting a message in the code pane and browsing senders, **it must always spawn a new MessageTrace** instead of mangling the to the list at the top.

The trace at the top is supposed to represent execution flow between the messages in the list, and NOT different random messages that derail the trace and make it a complete mess.

I also noticed this has been backported to 5.3.

• Chris

On Mon, Apr 27, 2020 at 2:32 AM commits@source.squeak.org wrote:

...

Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1652.mcz

==================== Summary ====================

Name: Morphic-mt.1652 Author: mt Time: 27 April 2020, 9:31:57.493264 am UUID: d23bbde5-4e42-3547-960d-39994fc21f56 Ancestors: Morphic-ct.1651

Fixes regression #browseIt in TraceMessages, too. Now all recent hick-ups with TraceMessages are gone. There are still some hooks missing such as #browseAllAccessTo:from:.

However, I think we should push down those backstops from Object to Model.

Note that I already backported this fix to Squeak 5.3.

=============== Diff against Morphic-ct.1651 ===============

Item was changed: ----- Method: TextEditor>>browseIt (in category 'menu messages') ----- browseIt "Launch a browser for the current selection, if appropriate."

    Preferences alternativeBrowseIt ifTrue: [^ self

browseClassFromIt].

    self lineSelectAndEmptyCheck: [^ morph flash].

    "First, try to show all accesses to instance or class variables."
    self selectedInstanceVariable ifNotNil:
            [:nameToClass | self systemNavigation
                    browseAllAccessesTo: nameToClass key
                    from: nameToClass value].
    self selectedClassVariable ifNotNil:

•           [:binding | self model browseAllCallsOn: binding].
  

•           [:binding | self systemNavigation browseAllCallsOn:
  

binding].

    "Then, either browse the class (from a binding) or all

implementors of a selector." self selectedBinding ifNotNil: [:binding | ^ self systemNavigation browseClass: binding]. self selectedSelector ifNotNil:

•           [:selector | ^ self model browseAllImplementorsOf:
  

selector].

•           [:selector | ^ self systemNavigation
  

browseAllImplementorsOf: selector].

    morph flash!

specifically, a quick Cmd+Shift+I to "invert" the selection at the selected level, followed by Cmd+d, is very helpful

Awesome, why did no one else tell me before? :D

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Chris Muller asqueaker@gmail.com Gesendet: Mittwoch, 12. Januar 2022 00:13:37 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)

P.S.: Your definition of "execution flow" is somewhat brittle since there are is no dynamic trace data involved. You rely on static analysis only. :-)

True. MessageTrace was never intended to perform dynamic analysis but it *is* aware of that issue by providing easy gestures for the user to quickly trim the unwanted extras (specifically, a quick Cmd+Shift+I to "invert" the selection at the selected level, followed by Cmd+d, is very helpful).

That would be cool if it could do dynamic analysis as an option, though.. :)

Hi Marcel,

When I press Cmd-m in a MessageTrace now, I now get a new window, when previously the methods were added to the current window as subordinates of the selected method.

From the message list, one can only expand the trace "upwards" because you

only have the method's own selector in the list. But to expand "downwards" you must use the code editor to select messages that are being sent from the selected method.

Kind regards, Jakob

Jakob and Christoph are right. Browsing Implementors from the code pane must continue the trace in the upper pane. I took a quick look, but a proper fix in line with Marcel's intentions for the code design wasn't 100% clear, so I refrained for now. Christoph's temporary solution works in the meantime.

On Thu, Jan 13, 2022 at 2:42 PM Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:

Hi all,

I am experiencing the same regression. IMHO it does not make any sense to honor the "trace messages" preference only in the message list, but not in the code pane. This preference has been working in the code pane even back in Squeak 5.2 and I would really appreciate gaining this behavior back. :-)

For a fix patch, you can comment out the anObject = #modelMenu check in MessageTrace>>#browseAllImplementorsOf:requestor: and #browseAllCallsOn:requestor:.

Best,

Christoph

---

Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Donnerstag, 13. Januar 2022 21:14:48 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)

Hi Marcel,

When I press Cmd-m in a MessageTrace now, I now get a new window, when previously the methods were added to the current window as subordinates of the selected method.

From the message list, one can only expand the trace "upwards" because you only have the method's own selector in the list. But to expand "downwards" you must use the code editor to select messages that are being sent from the selected method.

Kind regards, Jakob

Okay, here is something constructive. :-)

You can invoke senders/implementors in MessageTrace as follows:

(m1) Menu in message list, which considers the current message (selector) (m2) Keyboard shortcut in message list, which considers the current message (selector) (c1) Menu in code pade, which considers the current text selection (c2) Keyboard shortcut in code pane, which considers the current text selection (b) Click on the senders/implementors button between code pane and message list, which considers the current message (selector) but lets the user choose from a list of all other selectors in that message/method

Currently, (m1) and (m2) modify the trace while (c1) and (c2) and (b) open an new window. What should change?

Best, Marcel

P.S.: Before my recent change, (m1), (m2), (c1), and (c2) modified the trace while only (b) opened a new window. Then Chris called that a regression. ;-) Am 14.01.2022 10:25:01 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Huh? You guys are really entertaining me right now ... What exactly do you want here?

Chris wrote:

When selecting a message in the code pane and browsing senders, **it must always spawn a new MessageTrace** instead of mangling the to the list at the top.

So, I select a piece of text in the code pane and then hit CMD+N (being focused in the code pane)? Or that "senders" button? Or what?

Seriously ... This is not funny! Please try to be more clear. Provide screenshots.

Best, Marcel Am 14.01.2022 05:37:02 schrieb Chris Muller asqueaker@gmail.com: Jakob and Christoph are right. Browsing Implementors from the code pane must continue the trace in the upper pane. I took a quick look, but a proper fix in line with Marcel's intentions for the code design wasn't 100% clear, so I refrained for now. Christoph's temporary solution works in the meantime.

On Thu, Jan 13, 2022 at 2:42 PM Thiede, Christoph wrote:

Hi all,

I am experiencing the same regression. IMHO it does not make any sense to honor the "trace messages" preference only in the message list, but not in the code pane. This preference has been working in the code pane even back in Squeak 5.2 and I would really appreciate gaining this behavior back. :-)

For a fix patch, you can comment out the anObject = #modelMenu check in MessageTrace>>#browseAllImplementorsOf:requestor: and #browseAllCallsOn:requestor:.

Best,

Christoph

---

Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Donnerstag, 13. Januar 2022 21:14:48 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)

Hi Marcel,

When I press Cmd-m in a MessageTrace now, I now get a new window, when previously the methods were added to the current window as subordinates of the selected method.

From the message list, one can only expand the trace "upwards" because you only have the method's own selector in the list. But to expand "downwards" you must use the code editor to select messages that are being sent from the selected method.

Kind regards, Jakob

Hi Christoph --

Thanks for this clarification. If Chris agrees to this ... then I am still wondering what the "regression" was in the first place.

Best, Marcel Am 14.01.2022 16:04:07 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,

I did not start this debate, but I can understand your irritation. Thank you for the requestor interface on MessageTrace which keeps us all options open. Thank you for the overview of all possible invocation points. :-)

tl;dr: I would expect that (m2) and (c2) modify the trace (given that #traceMessages is enabled) and (b) opens a new window. Personally, I do not care about (m1) and (c1), but it would surely be useful to align them with (m2) and (c2). I think iMplementors and seNders should behave consistently for each invocation point.

Here is some more reasoning about my method. As Jakob already stated, pressing <cmd>m in the message list (m2) makes decent sense only, it is most important to be able to see all senders of a certain message in this list. So if I want to go *down* the chain of senders, I select a selector in the code pane (c2) and press <cmd>m to build a simplified call tree. For the other way around, going up the chain of senders, I select a message in the message list and press <cmd>n. In some situations, I want to observe multiple "routes", then I use the buttons (b) to spawn a new window.

For my first use case, I have attached a short screencast. For browsing senders from the code pane, it still *could* make sense to always spawn a new window, but on the other hand, this would make the handling of the tool less consistent, so I would always use the button for spawning.

Best, Christoph

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

On 2022-01-14T10:53:45+01:00, marcel.taeumel@hpi.de wrote:

Okay, here is something constructive. :-)

You can invoke senders/implementors in MessageTrace as follows:

(m1) Menu in message list, which considers the current message (selector) (m2) Keyboard shortcut in message list, which considers the current message (selector) (c1) Menu in code pade, which considers the current text selection (c2) Keyboard shortcut in code pane, which considers the current text selection (b) Click on the senders/implementors button between code pane and message list, which considers the current message (selector) but lets the user choose from a list of all other selectors in that message/method

Currently, (m1) and (m2) modify the trace while (c1) and (c2) and (b) open an new window. What should change?

Best, Marcel

P.S.: Before my recent change, (m1), (m2), (c1), and (c2) modified the trace while only (b) opened a new window. Then Chris called that a regression. ;-) Am 14.01.2022 10:25:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>: Huh? You guys are really entertaining me right now ... What exactly do you want here?

Chris wrote:

...

When selecting a message in the code pane and browsing senders, **it must always spawn a new MessageTrace** instead of mangling the to the list at the top.

So, I select a piece of text in the code pane and then hit CMD+N (being focused in the code pane)? Or that "senders" button? Or what?

Seriously ... This is not funny! Please try to be more clear. Provide screenshots.

Best, Marcel Am 14.01.2022 05:37:02 schrieb Chris Muller <asqueaker at gmail.com>: Jakob and Christoph are right. Browsing Implementors from the code pane must continue the trace in the upper pane. I took a quick look, but a proper fix in line with Marcel's intentions for the code design wasn't 100% clear, so I refrained for now. Christoph's temporary solution works in the meantime.

On Thu, Jan 13, 2022 at 2:42 PM Thiede, Christoph wrote:

...

Hi all,

I am experiencing the same regression. IMHO it does not make any sense to honor the "trace messages" preference only in the message list, but not in the code pane. This preference has been working in the code pane even back in Squeak 5.2 and I would really appreciate gaining this behavior back. :-)

For a fix patch, you can comment out the anObject = #modelMenu check in MessageTrace>>#browseAllImplementorsOf:requestor: and #browseAllCallsOn:requestor:.

Best,

Christoph

---

Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Donnerstag, 13. Januar 2022 21:14:48 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)

Hi Marcel,

When I press Cmd-m in a MessageTrace now, I now get a new window, when previously the methods were added to the current window as subordinates of the selected method.

From the message list, one can only expand the trace "upwards" because you only have the method's own selector in the list. But to expand "downwards" you must use the code editor to select messages that are being sent from the selected method.

Kind regards, Jakob

Aha! So, my misinterpretation was to read "browse senders" but understand "browse senders/implementors". We are getting somewhere ... :-) Chris?

Best, Marcel Am 14.01.2022 16:40:27 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de:

then I am still wondering what the "regression" was in the first place.

In Squeak 5.3, <cmd>m in the code pane adds the new messages to the existing window, whereas <cmd>n opens the new messages in a new window. Until last week, both added the new messages to the existing window. Since your recent patch, both opens them in a new window ...

I would agree with both 5.3 behavior (even though it is inconsistent and harder to learn) and with last week behavior. Chris? :-)

Best, Christoph

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

On 2022-01-14T16:07:16+01:00, marcel.taeumel@hpi.de wrote:

Hi Christoph --

Thanks for this clarification. If Chris agrees to this ... then I am still wondering what the "regression" was in the first place.

Best, Marcel Am 14.01.2022 16:04:07 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>: Hi Marcel,

I did not start this debate, but I can understand your irritation. Thank you for the requestor interface on MessageTrace which keeps us all options open. Thank you for the overview of all possible invocation points. :-)

tl;dr: I would expect that (m2) and (c2) modify the trace (given that #traceMessages is enabled) and (b) opens a new window. Personally, I do not care about (m1) and (c1), but it would surely be useful to align them with (m2) and (c2). I think iMplementors and seNders should behave consistently for each invocation point.

Here is some more reasoning about my method. As Jakob already stated, pressing <cmd>m in the message list (m2) makes decent sense only, it is most important to be able to see all senders of a certain message in this list. So if I want to go *down* the chain of senders, I select a selector in the code pane (c2) and press <cmd>m to build a simplified call tree. For the other way around, going up the chain of senders, I select a message in the message list and press <cmd>n. In some situations, I want to observe multiple "routes", then I use the buttons (b) to spawn a new window.

For my first use case, I have attached a short screencast. For browsing senders from the code pane, it still *could* make sense to always spawn a new window, but on the other hand, this would make the handling of the tool less consistent, so I would always use the button for spawning.

Best, Christoph

---

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

On 2022-01-14T10:53:45+01:00, marcel.taeumel at hpi.de wrote:

...

Okay, here is something constructive. :-)

You can invoke senders/implementors in MessageTrace as follows:

(m1) Menu in message list, which considers the current message (selector) (m2) Keyboard shortcut in message list, which considers the current message (selector) (c1) Menu in code pade, which considers the current text selection (c2) Keyboard shortcut in code pane, which considers the current text selection (b) Click on the senders/implementors button between code pane and message list, which considers the current message (selector) but lets the user choose from a list of all other selectors in that message/method

Currently, (m1) and (m2) modify the trace while (c1) and (c2) and (b) open an new window. What should change?

Best, Marcel

P.S.: Before my recent change, (m1), (m2), (c1), and (c2) modified the trace while only (b) opened a new window. Then Chris called that a regression. ;-) Am 14.01.2022 10:25:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>: Huh? You guys are really entertaining me right now ... What exactly do you want here?

Chris wrote:

...

When selecting a message in the code pane and browsing senders, **it must always spawn a new MessageTrace** instead of mangling the to the list at the top.

So, I select a piece of text in the code pane and then hit CMD+N (being focused in the code pane)? Or that "senders" button? Or what?

Seriously ... This is not funny! Please try to be more clear. Provide screenshots.

Best, Marcel Am 14.01.2022 05:37:02 schrieb Chris Muller <asqueaker at gmail.com>: Jakob and Christoph are right. Browsing Implementors from the code pane must continue the trace in the upper pane. I took a quick look, but a proper fix in line with Marcel's intentions for the code design wasn't 100% clear, so I refrained for now. Christoph's temporary solution works in the meantime.

On Thu, Jan 13, 2022 at 2:42 PM Thiede, Christoph wrote:

...

Hi all,

I am experiencing the same regression. IMHO it does not make any sense to honor the "trace messages" preference only in the message list, but not in the code pane. This preference has been working in the code pane even back in Squeak 5.2 and I would really appreciate gaining this behavior back. :-)

For a fix patch, you can comment out the anObject = #modelMenu check in MessageTrace>>#browseAllImplementorsOf:requestor: and #browseAllCallsOn:requestor:.

Best,

Christoph

---

Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Donnerstag, 13. Januar 2022 21:14:48 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)

Hi Marcel,

When I press Cmd-m in a MessageTrace now, I now get a new window, when previously the methods were added to the current window as subordinates of the selected method.

From the message list, one can only expand the trace "upwards" because you only have the method's own selector in the list. But to expand "downwards" you must use the code editor to select messages that are being sent from the selected method.

Kind regards, Jakob

*An exception could be if the selected selector is the selector of the current method. Then it could make sense to add to the trace instead. But I would not insist on that special case.

-1 for the extra complexity in the UI. :-)

That the buttons behave differently than the menu items in the code editor is actually inconsistent, but knowing that, I have become accustomed to using them if I do want a new window. I would not be too

concerned if that would change though (then they should behave like the actions in the code editor).

I have accustomed too, and I think we should always provide this "last resort" for opening a new window. It's pretty straightforward for me: Use your mouse if you want a new window, or use the keyboard if you want to stay in the existing window. On the other hand, in this model, we would probably also need to revise the behavior of the menu items. :-)

Best, Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Freitag, 14. Januar 2022 20:09:44 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)

Hi Marcel,

Am Fr., 14. Jan. 2022 um 17:05 Uhr schrieb Marcel Taeumel marcel.taeumel@hpi.de:

Aha! So, my misinterpretation was to read "browse senders" but understand "browse senders/implementors".

That was also my impression when I read your emails while cooking lunch today. ;-)

FWIW here are my expectations: - Menu and keyboard shortcut do the same thing - Senders in the message list: add to trace - Implementors in the message list: add to trace (but is seldom useful, only if you have previously deleted too many items from the trace) - Senders in the code editor: new window* - Implementors in the code editor: add to trace - Senders/Implementors Buttons: new window

*An exception could be if the selected selector is the selector of the current method. Then it could make sense to add to the trace instead. But I would not insist on that special case.

That the buttons behave differently than the menu items in the code editor is actually inconsistent, but knowing that, I have become accustomed to using them if I do want a new window. I would not be too concerned if that would change though (then they should behave like the actions in the code editor).

Kind regards, Jakob

Hi all --

Next take on fixing those regressions is live: Tools-mt.1107 :-)

Best, Marcel Am 18.01.2022 00:34:18 schrieb Chris Muller asqueaker@gmail.com: Hi Marcel,

Wow, I just saw all these new messages in this thread with "Chris?", sorry, I was busy all weekend!

Aha! So, my misinterpretation was to read "browse senders" but understand "browse senders/implementors". We are getting somewhere ... :-) Chris?

Correct! I never contradicted myself, but you're really busy and I now realize you must not use this feature, otherwise you would understand the purpose of the browser is to allow the user to easily build a coherent Trace in the upper pane, and not worrying about "consistency of behavior between panes".

Everything Jakob wrote under, "FWIW here are my expectations:" is exactly correct.

TracingMessages browser was my *very first contribution* to Squeak, way back in 2002. :) I ported exactly how it worked in the VisualAge version, and has been that way ever since. It's quite optimal, IMO.

You asked for screenshots, here's an *animated screenshot*. :)

https://www.youtube.com/watch?v=y96IvSwfXxg

I just checked Trunk and it appears it's still adding senders from the code pane to the upper pane. Again, I'm sorry for the frustration this has caused you. You're just helping us get this fixed with a good design, and you don't even use it. I'm truly grateful.

Best, Chris

Hi Chris --

[...] selecting "implementors" from the menu in the code pane, isn't adding to the lower pane [...]

Let me try to understand this by replacing "lower pane" with "upper pane" bc. that is where you can add something.

I make a text selection in the code pane, then open the menu, then click "More...", then click "implementors of it". This successfully adds stuff to the "upper pane" / "message list".

Best, Marcel Am 21.01.2022 03:44:09 schrieb Chris Muller asqueaker@gmail.com: Just did some quick testing, looks good, thanks.

I just noticed that selecting "implementors" from the menu in the code pane, isn't adding to the lower pane, but wasn't working in 5.2, either. I might fix that at some point.

- Chris

On Tue, Jan 18, 2022 at 3:13 AM Marcel Taeumel wrote:

Hi all --

Next take on fixing those regressions is live: Tools-mt.1107 :-)

Best, Marcel

Am 18.01.2022 00:34:18 schrieb Chris Muller :

Hi Marcel,

Wow, I just saw all these new messages in this thread with "Chris?", sorry, I was busy all weekend!

...

Aha! So, my misinterpretation was to read "browse senders" but understand "browse senders/implementors". We are getting somewhere ... :-) Chris?

Correct! I never contradicted myself, but you're really busy and I now realize you must not use this feature, otherwise you would understand the purpose of the browser is to allow the user to easily build a coherent Trace in the upper pane, and not worrying about "consistency of behavior between panes".

Everything Jakob wrote under, "FWIW here are my expectations:" is exactly correct.

TracingMessages browser was my *very first contribution* to Squeak, way back in 2002. :) I ported exactly how it worked in the VisualAge version, and has been that way ever since. It's quite optimal, IMO.

You asked for screenshots, here's an *animated screenshot*. :)

https://www.youtube.com/watch?v=y96IvSwfXxg

I just checked Trunk and it appears it's still adding senders from the code pane to the upper pane. Again, I'm sorry for the frustration this has caused you. You're just helping us get this fixed with a good design, and you don't even use it. I'm truly grateful.

Best, Chris

Hi Chris --

Selecting implementors from the menu in the upper pane (and then a selector from the subsequent presented menu)

Ah! Thanks. The button bar and the upper pane's menu share the same behavior. I did not notice that. Sure. That was the last inconsistency Jakob was talking about. We can fix that.

Best, Marcel Am 22.01.2022 03:37:44 schrieb Chris Muller ma.chris.m@gmail.com:

[...] selecting "implementors" from the menu in the code pane, isn't adding to the lower pane [...]

Let me try to understand this by replacing "lower pane" with "upper pane" bc. that is where you can add something.

Sorry, I meant the upper pane, not the code pane.  Selecting implementors from the menu in the upper pane (and then a selector from the subsequent presented menu), should add the implemented message(s) to the upper pane, indented below the current selection, just as if it was selected in the lower pane.

Doing that same thing except selecting "senders" from that same menu, is also just as if it was selected in the lower pane -- opens a new window.   I make a text selection in the code pane, then open the menu, then click "More...", then click "implementors of it". This successfully adds stuff to the "upper pane" / "message list".

Yes, the code / lower pane is working perfectly.  Thanks!   Best,   Chris

With that fix, it's now working better than it ever has! :) Thank you.

On Sat, Jan 22, 2022 at 3:05 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi Chris --

See Tools-mt.1109 (Trunk).

Best, Marcel

Am 22.01.2022 09:43:21 schrieb Marcel Taeumel marcel.taeumel@hpi.de:

Hi Chris --

...

Selecting implementors from the menu in the upper pane (and then a selector from the subsequent presented menu)

Ah! Thanks. The button bar and the upper pane's menu share the same behavior. I did not notice that. Sure. That was the last inconsistency Jakob was talking about. We can fix that.

Best, Marcel

Am 22.01.2022 03:37:44 schrieb Chris Muller ma.chris.m@gmail.com:

...

...

[...] selecting "implementors" from the menu in the code pane, isn't adding to the lower pane [...]

Let me try to understand this by replacing "lower pane" with "upper pane" bc. that is where you can add something.

Sorry, I meant the upper pane, not the code pane. Selecting implementors from the menu in the upper pane (and then a selector from the subsequent presented menu), should add the implemented message(s) to the upper pane, indented below the current selection, just as if it was selected in the lower pane.

Doing that same thing except selecting "senders" from that same menu, is also just as if it was selected in the lower pane -- opens a new window.

...

I make a text selection in the code pane, then open the menu, then click "More...", then click "implementors of it". This successfully adds stuff to the "upper pane" / "message list".

Yes, the code / lower pane is working perfectly. Thanks!

Best, Chris

On 2022-02-06, at 12:59 PM, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:

I kindly request that we map the buttons again to spawning a new window. Or do you have any better idea? Maybe define a modifier key (Shift) for this? But for the buttons, Shift already has another meaning (please choose selector) ...

This is what happens when we have a pathetic 26 letters in our alphabet instead of the much more sensible approach written Chinese has; no clashes with a gazillion 'letters' to choose from ;-)

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When you earnestly believe you can compensate for a lack of skill by doubling your efforts, there's no end to what you can't do

Hi Chris,

sorry for the delay. Exams and things and other things, you know. :-)

You simply shed your aversion to the green halo! ;-p

Yeah, I should use that green halo more often. :D I'm always afraid that I could clone the world by accident. This has already happened to me in the past. Back to topic, cloning a message trace gives me a copy of the previous *session*, not a new and clean window. I would have to select all other messages after cloning and delete them ...

Just to be clear, nothing is different than what it was before it got broken in 5.3.

In Squeak 5.2 (and also 5.3), I could do this:

1. Type foo 2. Browse iMplementors 3. Select the first method 4. Press the "senders" button 5. And a second message trace on the senders of #foo opens.

This no longer works since the recent changes.

Cmd+c+0+v+m. :)

I know and sometimes do that. But you won't be able to convince me that this could be as fast as a single button. Also, the search bar/scratch pad do not provide support for stacking these conceptual breaks, sometimes I am parking another doit script there and then my keyboard sequence extends to:

Cmd+c+0+home+v+(shift)pos1+m+0+del. :D

But, I don't care about (b). Traces are normally built via the upper and lower pane functions, not the middle button row. So, ONLY for the button row between the panes, it seems fine for it to unconditionally open a new window. If it's possible to twiggle it dynamically with a modifier key,

that'd be preferable but, even if not, it seems reasonable to open a new window. But we need to maintain the legacy behaviors for the upper and lower panes, please.

Alright, please see Tools-ct.1136. I still do not consider this a perfect and maximally intuitive solution, but apparently we are a few users of this tool only, so if we can find a heuristic that satisfies everyone, this might not be a big problem. :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2022-02-07T20:00:29-06:00, asqueaker@gmail.com wrote:

Hi Christoph,

Sorry for objecting again, and sorry for not noticing this earlier:

...

Currently, there appears not to be *any* way to browse senders/implementors of a selected message in a new window rather than the existing one (except for workarounds such as turning off the preference temporarily or dirtying your contents pane). In some situations, I just need to do a "conceptual break" by starting a "separate message trace session". I'm sad that this is not possible any longer. :-(

Of course it is! You simply shed your aversion to the green halo! ;-p

Just to be clear, nothing is different than what it was before it got broken in 5.3.

And you can still even do it with the keyboard. Cmd+c+0+v+m. :) Sure, it's an extra press relative to a modifier key, but it's still quick, and totally fine for a conceptual break. Isn't it?

...

Allow me to cite myself from above:

...

tl;dr: I would expect that (m2) and (c2) modify the trace (given that

#traceMessages is enabled) and *(b) opens a new window.* Personally, I do not care about (m1) and (c1), but it would surely be useful to align them with (m2) and (c2).

I think iMplementors and seNders should behave consistently for each

...

invocation point.

No, the browser is about building a flow of execution, not collecting a "batch of messages".

...

I kindly request that we map the buttons again to spawning a new window. Or do you have any better idea? Maybe define a modifier key (Shift) for this? But for the buttons, Shift already has another meaning (please choose selector) ...

But, I don't care about (b). Traces are normally built via the upper and lower pane functions, not the middle button row. So, ONLY for the button row between the panes, it seems fine for it to unconditionally open a new window. If it's possible to twiggle it dynamically with a modifier key, that'd be preferable but, even if not, it seems reasonable to open a new window. But we need to maintain the legacy behaviors for the upper and lower panes, please.

Best, Chris

Hi Chris,

...

...

Just to be clear, nothing is different than what it was before it got

broken in 5.3.

In Squeak 5.2 (and also 5.3), I could do this:

1. Type foo
2. Browse iMplementors
3. Select the first method
4. Press the "senders" button
5. And a second message trace on the senders of #foo opens.

"A second message trace" as in a second window? That's not the behavior I see. That should only happen if traceMessages was not enabled, or if the keyboard focus was somewhere besides the upper pane.

Please see the attached screencast which I recorded in a fresh 5.2 image. :-)

So, you want to be able to only forward trace (e.g., add indended implementors) but replace ability to back trace (add outdented senders) with only starting yet a new trace? If so, I'm puzzled why you would want that. Back tracing is useful but there'd be no way to do it if it always opened a new window.

It just depends on the use case. In many situations, backtracing is helpful so I'm fine with reusing the existing window, but in other situations, my conceptual model is to start a new session. I want to explore two different routes through a program/through the system that should not intermix each other. In this case, I need a new and clear and empty window. :-)

I'm not sure if you feel your change is an optimization of that use-case, or a different one..

It is a change to make sure that the old behavior of breaking out of the trace is still possible. :-)

PS: Yes, that scratch pad feature is indeed very nice. Looking forward to trying it out when attached to the mouse cursor. :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2022-02-26T18:13:10-06:00, asqueaker@gmail.com wrote:

Hi,

sorry for the delay. Exams and things and other things, you know. :-)

...

:-)

...

...

Just to be clear, nothing is different than what it was before it got

broken in 5.3.

In Squeak 5.2 (and also 5.3), I could do this:

1. Type foo
2. Browse iMplementors
3. Select the first method
4. Press the "senders" button
5. And a second message trace on the senders of #foo opens.

"A second message trace" as in a second window? That's not the behavior I see. That should only happen if traceMessages was not enabled, or if the keyboard focus was somewhere besides the upper pane.

...

This no longer works since the recent changes.

So, you want to be able to only forward trace (e.g., add indended implementors) but replace ability to back trace (add outdented senders) with only starting yet a new trace? If so, I'm puzzled why you would want that. Back tracing is useful but there'd be no way to do it if it always opened a new window.

...

...

Cmd+c+0+v+m. :)

I know and sometimes do that. But you won't be able to convince me that this could be as fast as a single button. Also, the search bar/scratch pad do not provide support for stacking these conceptual breaks,

sometimes I am parking another doit script there ...

...

Actually, that's precisely why the "scratch pad" was hacked in -- it's multi-line. There's your "stack". :) Rudimentary, I know, but it works. Undo also works.

Side note: the scratch pad in the upper right is a temporary hack -- I always wanted Cmd+0 to open a BalloonMorph at the hand with the cursor ready to type, so the user's eyes don't always have to traverse back and forth to the upper right and back..

...

But, I don't care about (b). Traces are normally built via the upper and lower pane functions, not the middle button row. So, ONLY for the button row between the panes, it seems fine for it to unconditionally open a new window. If it's possible to twiggle it dynamically with a modifier key, that'd be preferable but, even if not, it seems reasonable to open a new window. But we need to maintain the legacy behaviors for the upper and lower panes, please.

Alright, please see Tools-ct.1136. I still do not consider this a perfect and maximally intuitive solution, but apparently we are a few users of this tool only, so if we can find a heuristic that satisfies everyone, this might not be a big problem. :-)

The heuristic is for building Traces. I'm not sure if you feel your change is an optimization of that use-case, or a different one..

Best, Chris

On Mon, Feb 28, 2022 at 9:58 AM christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi Marcel, hi all,

replying to your critique in "The Inbox: Tools-ct.1136.mcz" in this thread:

I made another attempt to assemble all our requirements for spawning vs tracing in the MessageTrace. The following list of requirements appears to have been agreed by Chris, Jakob, and me:

*- Menu and keyboard shortcut do the same thing - Senders in the message list: add to trace - Implementors in the message list: add to trace - Senders in the code editor: new window - Implementors in the code editor: add to trace - Senders/Implementors Buttons: new window *

I want to add a new requirement: a single modifier key causes the new query to be opened in a new window, not added to the trace. I like MessageTrace, but at a certain level of nesting I want to *not* pollute the results I already have by adding to the trace. This frustration happens a lot.

(Hm, that feels a lot like a logic puzzle. :D)

I have rechecked and Tools-ct.1136 seems to satisfy each of these requirements. :-)

Regarding your critique:

...

Let's keep menu click and button-bar click consistent.

My argument for just *not* connecting them to the same behavior is this: The button bar is common to all tools (browser, debugger, ...) and users can expect that it will always open a new tool. On the other hand, the menu is a trace-specific feature, you are triggering it through the core view representing the trace (the message list), so it makes a lot of sense to me display the result of the menu operations right in the trace.

...

We have #browseSendersOfMessages ... button bar + popup menu

#browseSenders ... text/list keyboard shortcuts

...

It's confusing enough that there are two paths. What I would agree with

is when we spawn a new window for the #browseSendersOfMessages, which you can easily distinguish via requestor being #modelMenu.

To be honest, that sounds more like an implementation-first than like a UX-first argument to me. :-) Maybe the mapping from the different interactions to the protocol does not match the tool in question very well. IMO (as Jakob mentioned earlier) *a menu item and its shortcut should trigger the same code path.* Ideally, the requestor in #browseAllCallsOn:requestor:/#browseAllImplementorsOf:requestor: should identify the widget where the event was received, not the kind of user interaction (mouse vs. keyboard).

tl;dr: I still like my proposal in Tools-ct.1136, and if you are expecting different semantics of the tool, please let's work together on revising the list of requirements from above. In this case I am convinced that UX should be valued higher than the aesthetics of the implementation. :-)

Best, Christoph

---

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

On 2022-02-28T09:32:12+01:00, marcel.taeumel@hpi.de wrote:

...

Oh, my. -1 :-)

Let's keep menu click and button-bar click consistent.

We have #browseSendersOfMessages ... button bar + popup menu #browseSenders ... text/list keyboard shortcuts

It's confusing enough that there are two paths. What I would agree with

is when we spawn a new window for the #browseSendersOfMessages, which you can easily distinguish via requestor being #modelMenu.

...

Best, Marcel Am 25.02.2022 16:51:30 schrieb commits at source.squeak.org <commits at

source.squeak.org>:

...

A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-ct.1136.mcz

==================== Summary ====================

Name: Tools-ct.1136 Author: ct Time: 25 February 2022, 4:51:14.742129 pm UUID: d3396d11-145e-294d-b51c-805c6b3b64ab Ancestors: Tools-mt.1135

Revises senders/implementors in message traces so that:

• using the buttons always spawns a new window
• you can press shift to invert whether the new messages will be

appended to the existing window or opened in a new window

...

See:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-February/218946....

...

=============== Diff against Tools-mt.1135 ===============

Item was changed: ----- Method: MessageTrace>>browseAllCallsOn:requestor: (in category

'actions') -----

...

browseAllCallsOn: selectorSymbol requestor: anObject "Overwritten to modify the trace if the request origins from a

model-menu command such as the message-list menu (shortcut)."

...

• (((Preferences traceMessages and: [anObject ~= #button] and:

[selectorSymbol = self selectedMessageName]) xor: Sensor shiftPressed)

...

• and: [self hasUnacceptedEdits not])

• (selectorSymbol = self selectedMessageName
• and: [ Preferences traceMessages ] and: [ self hasUnacceptedEdits not

])

...

ifTrue: [ self addParentMethodsSending: selectorSymbol ] ifFalse: [ super browseAllCallsOn: selectorSymbol requestor: anObject ].!

Item was changed: ----- Method: MessageTrace>>browseAllImplementorsOf:requestor: (in

category 'actions') -----

...

browseAllImplementorsOf: selectorSymbol requestor: anObject "Overwritten to modify the trace if the request origins from a

model-menu command such as the message-list menu (shortcut)."

...

| selectorToBrowse | selectorToBrowse := self selection ifNil: [ selectorSymbol ] ifNotNil: [ self getImplementorNamed: selectorSymbol asSymbol "since we

can get passed literals"].

...

• (((Preferences traceMessages and: [anObject ~= #button]) xor: Sensor

shiftPressed) and: [self hasUnacceptedEdits not])

...

• (Preferences traceMessages and: [ self hasUnacceptedEdits not ])

ifTrue: [ self addChildMethodsNamed: selectorToBrowse ] ifFalse: [ super browseAllImplementorsOf: selectorToBrowse requestor:

anObject ].!

...

Item was added:

• ----- Method: MessageTrace>>browseMessagesFromButton (in category

'controls') -----

...

• browseMessagesFromButton
• self getSelectorAndSendQuery: #browseAllImplementorsOf:requestor: to:

self with: #(button).!

...

Item was added:

• ----- Method: MessageTrace>>browseSendersOfMessagesFromButton (in

category 'controls') -----

...

• browseSendersOfMessagesFromButton
• self getSelectorAndSendQuery: #browseAllCallsOn:requestor: to: self

with: #(button).!

...

Item was added:

• ----- Method: MessageTrace>>optionalButtonPairs (in category

'controls') -----

...

• optionalButtonPairs
• ^ super optionalButtonPairs collect: [:spec |
• spec second
• caseOf:
• {[#browseSendersOfMessages] -> [spec copy
• at: 2 put: #browseSendersOfMessagesFromButton;
• yourself].
• [#browseMessages] -> [spec copy
• at: 2 put: #browseMessagesFromButton;
• yourself]}
• otherwise: [spec]]!

...

I want to add a new requirement: a single modifier key causes the new

query to be opened in a new window, not added to the trace. I like MessageTrace, but at a certain level of nesting I want to *not* pollute the results I already have by adding to the trace. This frustration happens a lot.

I'd like to make a UI suggestion that would ameliorate quite a few cases of this need - use a PluggableTreeMorph (as we do in the Explorer-inspector) to show the tree of messages. It would allow a bit more control over what you see at any point, without removing messages with the cmd-D etc as now.

No, please do not do that! PluggableListMorphOfMany2 was created specifically for this browser so that a specific kind of nimble interaction, which is shown and even explicitly mentioned in the youtube video, would be possible. Tree widget is how Pharo did it (I think, it's been a while), and it was a plodding, confusing experience. The design of this browser really is driven by the UX and not the model.

- Chris

This is another one of those things where different people do things differently. I find the current tool really annoying once I get beyond a very few layers. I don't find the simple text indenting at all helpful once we are past a couple of layers. I don't find the cmd-D stuff very helpful in practice.

For *me* an Explorer-like rake would be much more usable wrt seeing what is happening. I do, however, see your point about the all-or-nothing issue; certainly having the 9400-ish senders of #new would be a bit of a pain. Then again, it's not so good in the current tool either, but very large lists are always hard to do UI for.

Adding a 'hide these'/cmd-d capability to the treemorph might be an interesting way to get the best of both worlds. It would provide a sort of cmd-z too, just click on the 'hidden things' to re-open them.

I would point out that I'm *not* suggesting making a UI that 'opens up' a method and shows all the implementors of all the messages in that selected method. I would still want to use the same cmd-n/m stuff; I just want it visually presented in a way that works for my perception.

On 2022-02-28, at 5:43 PM, Chris Muller asqueaker@gmail.com wrote:

I'd like to make a UI suggestion that would ameliorate quite a few cases of this need - use a PluggableTreeMorph (as we do in the Explorer-inspector) to show the tree of messages.

I remember now. In Pharo's, there was no need to select "implementors" at all, you simply keep expanding the tree of sent messages. I don't think it could backtrace at all, though.

It would allow a bit more control over what you see at any point, without removing messages with the cmd-D etc as now.

It'd be less control, not more, because you can't trim individual levels with Cmd+d. You'll always have either all 67 #at:'s (expanded) including the ones totally unrelated to what you want, OR none of them (collapsed). Try out Pharo's, you'll probably hate it. So you can't get rid of Cmd+d, and nor would it be good to combine it with expand / collapse capability, because those functions would be confusingly ambiguous to the goal of tracing code.

• Chris

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Runs squares around the competition.

Hi all,

if no one objects again, I will merge Tools-ct.1136 into the Trunk in a few days. :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2022-03-25T19:06:54+01:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:

...

Adding a 'hide these'/cmd-d capability to the treemorph might be an interesting way to get the best of both worlds. It would provide a sort of cmd-z too, just click on the 'hidden things' to re-open them.

+1. In the long term, I think it should be possible to build a tree-view-based MessageTrace that has all features from the current tool, plus even more. :-) But it's a long way until we can be there - currently, PluggableTreeMorph does not even support multiselection.

So, apart from all these feature dreams - what are your final opinions about Tools-ct.1136 for now? Eliot, have you given it a try? I think it already contains the modifier key you requested. :-) What do you think, Marcel? :-)

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2022-02-28T18:07:43-08:00, tim at rowledge.org wrote:

...

This is another one of those things where different people do things differently. I find the current tool really annoying once I get beyond a very few layers. I don't find the simple text indenting at all helpful once we are past a couple of layers. I don't find the cmd-D stuff very helpful in practice.

For *me* an Explorer-like rake would be much more usable wrt seeing what is happening. I do, however, see your point about the all-or-nothing issue; certainly having the 9400-ish senders of #new would be a bit of a pain. Then again, it's not so good in the current tool either, but very large lists are always hard to do UI for.

Adding a 'hide these'/cmd-d capability to the treemorph might be an interesting way to get the best of both worlds. It would provide a sort of cmd-z too, just click on the 'hidden things' to re-open them.

I would point out that I'm *not* suggesting making a UI that 'opens up' a method and shows all the implementors of all the messages in that selected method. I would still want to use the same cmd-n/m stuff; I just want it visually presented in a way that works for my perception.

...

On 2022-02-28, at 5:43 PM, Chris Muller <asqueaker at gmail.com> wrote:

I'd like to make a UI suggestion that would ameliorate quite a few cases of this need - use a PluggableTreeMorph (as we do in the Explorer-inspector) to show the tree of messages.

I remember now. In Pharo's, there was no need to select "implementors" at all, you simply keep expanding the tree of sent messages. I don't think it could backtrace at all, though.

It would allow a bit more control over what you see at any point, without removing messages with the cmd-D etc as now.

It'd be less control, not more, because you can't trim individual levels with Cmd+d. You'll always have either all 67 #at:'s (expanded) including the ones totally unrelated to what you want, OR none of them (collapsed). Try out Pharo's, you'll probably hate it. So you can't get rid of Cmd+d, and nor would it be good to combine it with expand / collapse capability, because those functions would be confusingly ambiguous to the goal of tracing code.

• Chris

tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- Runs squares around the competition.

Hi Jakob, hi Chris, hi Christoph --

Haha, you are funny. You have to agree on some common behavior. First, Chris called it a regression that MessageTrace is changed when hitting CMD+M in the code pane and now Jakob+Christoph are saying that it is a regression that you cannot do so anymore.

Well, I gave you a design where you can decide what you really want in a single place:

MessageTrace>>#browseAllImplementorsOf:requestor: MessageTrace>>#browseAllCallsOn:requestor:

Personally, I think that it is a good thing that you can escape the MessageTrace when you hit CMD+M in the code pane but stay within that tool when you hit CMD+M in the message list above.

You decide. But we aware that there seems to be a conflict between what Chris wants and what Christoph/Jakob wants. ;-)

Best, Marcel Am 13.01.2022 21:42:22 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi all,

I am experiencing the same regression. IMHO it does not make any sense to honor the "trace messages" preference only in the message list, but not in the code pane. This preference has been working in the code pane even back in Squeak 5.2 and I would really appreciate gaining this behavior back. :-)

For a fix patch, you can comment out the anObject = #modelMenu check in MessageTrace>>#browseAllImplementorsOf:requestor: and #browseAllCallsOn:requestor:.

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Donnerstag, 13. Januar 2022 21:14:48 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)   Hi Marcel,

When I press Cmd-m in a MessageTrace now, I now get a new window, when previously the methods were added to the current window as subordinates of the selected method.

From the message list, one can only expand the trace "upwards" because you only have the method's own selector in the list. But to expand "downwards" you must use the code editor to select messages that are being sent from the selected method.

Kind regards, Jakob