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 at 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220226/e58c5d33/attachment.html>
> 
> 
["messagetrace-5.2.gif"]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220228/2a1a5997/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: messagetrace-5.2.gif
Type: image/gif
Size: 297959 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220228/2a1a5997/attachment-0001.gif>