Hi Chris,<br>
<br>
> > > Just to be clear, nothing is different than what it was before it got<br>
> > broken in 5.3.<br>
> ><br>
> > In Squeak 5.2 (and also 5.3), I could do this:<br>
> ><br>
> > 1. Type foo<br>
> > 2. Browse iMplementors<br>
> > 3. Select the first method<br>
> > 4. Press the "senders" button<br>
> > 5. And a second message trace on the senders of #foo opens.<br>
> ><br>
> <br>
> "A second message trace" as in a second window?  That's not the behavior I<br>
> see.  That should only happen if traceMessages was not enabled, or if the<br>
> keyboard focus was somewhere besides the upper pane.<br>
<br>
Please see the attached screencast which I recorded in a fresh 5.2 image. :-)<br>
<br>
> So, you want to be able to only forward trace (e.g., add indended<br>
> implementors) but replace ability to back trace (add outdented senders)<br>
> with only starting yet a new trace?  If so, I'm puzzled why you would want<br>
> that.  Back tracing is useful but there'd be no way to do it if it always<br>
> opened a new window.<br>
<br>
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. :-)<br>
<br>
> I'm not sure if you feel your change is an optimization of that use-case, or a different one..<br>
<br>
It is a change to make sure that the old behavior of breaking out of the trace is still possible. :-)<br>
<br>
PS: Yes, that scratch pad feature is indeed very nice. Looking forward to trying it out when attached to the mouse cursor. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font 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></font><br>
<br>
On 2022-02-26T18:13:10-06:00, asqueaker@gmail.com wrote:<br>
<br>
> Hi,<br>
> <br>
> sorry for the delay. Exams and things and other things, you know. :-)<br>
> ><br>
> <br>
> :-)<br>
> <br>
> <br>
> > > Just to be clear, nothing is different than what it was before it got<br>
> > broken in 5.3.<br>
> ><br>
> > In Squeak 5.2 (and also 5.3), I could do this:<br>
> ><br>
> > 1. Type foo<br>
> > 2. Browse iMplementors<br>
> > 3. Select the first method<br>
> > 4. Press the "senders" button<br>
> > 5. And a second message trace on the senders of #foo opens.<br>
> ><br>
> <br>
> "A second message trace" as in a second window?  That's not the behavior I<br>
> see.  That should only happen if traceMessages was not enabled, or if the<br>
> keyboard focus was somewhere besides the upper pane.<br>
> <br>
> <br>
> > This no longer works since the recent changes.<br>
> ><br>
> <br>
> So, you want to be able to only forward trace (e.g., add indended<br>
> implementors) but replace ability to back trace (add outdented senders)<br>
> with only starting yet a new trace?  If so, I'm puzzled why you would want<br>
> that.  Back tracing is useful but there'd be no way to do it if it always<br>
> opened a new window.<br>
> <br>
> <br>
> > > Cmd+c+0+v+m. :)<br>
> ><br>
> > I know and sometimes do that. But you won't be able to convince me that<br>
> > this could be as fast as a single button. Also, the search bar/scratch pad<br>
> > do not provide support for stacking these conceptual breaks,<br>
> <br>
> sometimes I am parking another doit script there ...<br>
> ><br>
> <br>
> Actually, that's precisely why the "scratch pad" was hacked in -- it's<br>
> multi-line.  There's your "stack".  :)  Rudimentary, I know, but it works.<br>
> Undo also works.<br>
> <br>
> Side note:  the scratch pad in the upper right is a temporary hack -- I<br>
> always wanted Cmd+0 to open a BalloonMorph at the hand with the cursor<br>
> ready to type, so the user's eyes don't always have to traverse back and<br>
> forth to the upper right and back..<br>
> <br>
> > But, I don't care about (b). Traces are normally built via the upper and<br>
> > lower pane functions, not the middle button row. So, ONLY for the button<br>
> > row between the panes, it seems fine for it to unconditionally open a new<br>
> > window. If it's possible to twiggle it dynamically with a modifier key,<br>
> > that'd be preferable but, even if not, it seems reasonable to open a new<br>
> > window. But we need to maintain the legacy behaviors for the upper and<br>
> > lower panes, please.<br>
> ><br>
> > Alright, please see Tools-ct.1136. I still do not consider this a perfect<br>
> > and maximally intuitive solution, but apparently we are a few users of this<br>
> > tool only, so if we can find a heuristic that satisfies everyone, this<br>
> > might not be a big problem. :-)<br>
> ><br>
> <br>
> The heuristic is for building Traces.  I'm not sure if you feel your change<br>
> is an optimization of that use-case, or a different one..<br>
> <br>
> Best,<br>
>   Chris<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220226/e58c5d33/attachment.html><br>
> <br>
> <br>
["messagetrace-5.2.gif"]