<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Aha! So, my misinterpretation was to read "browse senders" but understand "browse senders/implementors". We are getting somewhere ... :-) Chris?<div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 14.01.2022 16:40:27 schrieb christoph.thiede@student.hpi.uni-potsdam.de <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style='font-family:Arial,Helvetica,sans-serif'>
> then I am still wondering what the "regression" was in the first place.<br>
<br>
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 ...<br>
<br>
I would agree with both 5.3 behavior (even though it is inconsistent and harder to learn) and with last week behavior. Chris? :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<span style="color: #808080">---<br>
</span><span style="color: #808080"><i>Sent from </i></span><span style="color: #808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></span><br>
<br>
On 2022-01-14T16:07:16+01:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> Hi Christoph --<br>
> <br>
> Thanks for this clarification. If Chris agrees to this ... then I am still wondering what the "regression" was in the first place.<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 14.01.2022 16:04:07 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> Hi Marcel,<br>
> <br>
> 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. :-)<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Best,<br>
> Christoph<br>
> <br>
> ---<br>
> Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]<br>
> <br>
> On 2022-01-14T10:53:45+01:00, marcel.taeumel at hpi.de wrote:<br>
> <br>
> > Okay, here is something constructive. :-)<br>
> ><br>
> > You can invoke senders/implementors in MessageTrace as follows:<br>
> ><br>
> > (m1) Menu in message list, which considers the current message (selector)<br>
> > (m2) Keyboard shortcut in message list, which considers the current message (selector)<br>
> > (c1) Menu in code pade, which considers the current text selection<br>
> > (c2) Keyboard shortcut in code pane, which considers the current text selection<br>
> > (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<br>
> ><br>
> > Currently, (m1) and (m2) modify the trace while (c1) and (c2) and (b) open an new window. What should change?<br>
> ><br>
> > Best,<br>
> > Marcel<br>
> ><br>
> > 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. ;-)<br>
> > Am 14.01.2022 10:25:01 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:<br>
> > Huh? You guys are really entertaining me right now ... What exactly do you want here?<br>
> ><br>
> > Chris wrote:<br>
> > >  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.<br>
> ><br>
> > 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?<br>
> ><br>
> > Seriously ... This is not funny! Please try to be more clear. Provide screenshots.<br>
> ><br>
> > Best,<br>
> > Marcel<br>
> > Am 14.01.2022 05:37:02 schrieb Chris Muller <asqueaker at gmail.com>:<br>
> > Jakob and Christoph are right. Browsing Implementors from the code<br>
> > pane must continue the trace in the upper pane. I took a quick<br>
> > look, but a proper fix in line with Marcel's intentions for the code<br>
> > design wasn't 100% clear, so I refrained for now. Christoph's<br>
> > temporary solution works in the meantime.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jan 13, 2022 at 2:42 PM Thiede, Christoph<br>
> > wrote:<br>
> > ><br>
> > > Hi all,<br>
> > ><br>
> > ><br>
> > > 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. :-)<br>
> > ><br>
> > ><br>
> > > For a fix patch, you can comment out the anObject = #modelMenu check in MessageTrace>>#browseAllImplementorsOf:requestor: and #browseAllCallsOn:requestor:.<br>
> > ><br>
> > ><br>
> > > Best,<br>
> > ><br>
> > > Christoph<br>
> > ><br>
> > > ________________________________<br>
> > > Von: Squeak-dev im Auftrag von Jakob Reschke<br>
> > > Gesendet: Donnerstag, 13. Januar 2022 21:14:48<br>
> > > An: The general-purpose Squeak developers list<br>
> > > Betreff: Re: [squeak-dev] bad MessageTrace regression (was: The Trunk: Morphic-mt.1652.mcz)<br>
> > ><br>
> > > Hi Marcel,<br>
> > ><br>
> > > 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.<br>
> > ><br>
> > > 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.<br>
> > ><br>
> > > Kind regards,<br>
> > > Jakob<br>
> > ><br>
> ><br>
> > -------------- next part --------------<br>
> > An HTML attachment was scrubbed...<br>
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/039e63ac/attachment.html><br>
> ><br>
> ><br>
> ["message-trace-m.gif"]<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/cbfe1f66/attachment.html><br>
> <br>

</div></blockquote>
                                        </div></body>