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 at 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220207/949eacdb/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220225/57139e2e/attachment.html>