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>