Hi Marcel, hi all,<br>
<br>
replying to your critique in "The Inbox: Tools-ct.1136.mcz" in this thread:<br>
<br>
I made another attempt to assemble all our requirements for spawning vs tracing in the MessageTrace. The following list of requirements appears to have been agreed by Chris, Jakob, and me:<br>
<br>
<i>- Menu and keyboard shortcut do the same thing<br>
- Senders in the message list: add to trace<br>
- Implementors in the message list: add to trace<br>
- Senders in the code editor: new window<br>
- Implementors in the code editor: add to trace<br>
- Senders/Implementors Buttons: new window<br>
</i><br>
(Hm, that feels a lot like a logic puzzle. :D)<br>
<br>
I have rechecked and Tools-ct.1136 seems to satisfy each of these requirements. :-)<br>
<br>
Regarding your critique:<br>
<br>
> Let's keep menu click and button-bar click consistent. <br>
<br>
My argument for just *not* connecting them to the same behavior is this: The button bar is common to all tools (browser, debugger, ...) and users can expect that it will always open a new tool. On the other hand, the menu is a trace-specific feature, you are triggering it through the core view representing the trace (the message list), so it makes a lot of sense to me display the result of the menu operations right in the trace.<br>
<br>
> We have #browseSendersOfMessages ... button bar + popup menu #browseSenders ... text/list keyboard shortcuts<br>
> <br>
> It's confusing enough that there are two paths. What I would agree with is when we spawn a new window for the #browseSendersOfMessages, which you can easily distinguish via requestor being #modelMenu.<br>
<br>
To be honest, that sounds more like an implementation-first than like a UX-first argument to me. :-) Maybe the mapping from the different interactions to the protocol does not match the tool in question very well. IMO (as Jakob mentioned earlier) <b>a menu item and its shortcut should trigger the same code path.</b> Ideally, the requestor in #browseAllCallsOn:requestor:/#browseAllImplementorsOf:requestor: should identify the widget where the event was received, not the kind of user interaction (mouse vs. keyboard).<br>
<br>
tl;dr: I still like my proposal in Tools-ct.1136, and if you are expecting different semantics of the tool, please let's work together on revising the list of requirements from above. In this case I am convinced that UX should be valued higher than the aesthetics of the implementation. :-)<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-28T09:32:12+01:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> Oh, my. -1 :-)<br>
> <br>
> Let's keep menu click and button-bar click consistent. <br>
> <br>
> We have<br>
> #browseSendersOfMessages ... button bar + popup menu<br>
> #browseSenders ... text/list keyboard shortcuts<br>
> <br>
> It's confusing enough that there are two paths. What I would agree with is when we spawn a new window for the #browseSendersOfMessages, which you can easily distinguish via requestor being #modelMenu.<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 25.02.2022 16:51:30 schrieb commits at source.squeak.org <commits at source.squeak.org>:<br>
> A new version of Tools was added to project The Inbox:<br>
> http://source.squeak.org/inbox/Tools-ct.1136.mcz<br>
> <br>
> ==================== Summary ====================<br>
> <br>
> Name: Tools-ct.1136<br>
> Author: ct<br>
> Time: 25 February 2022, 4:51:14.742129 pm<br>
> UUID: d3396d11-145e-294d-b51c-805c6b3b64ab<br>
> Ancestors: Tools-mt.1135<br>
> <br>
> Revises senders/implementors in message traces so that:<br>
> <br>
> * using the buttons always spawns a new window<br>
> * you can press shift to invert whether the new messages will be appended to the existing window or opened in a new window<br>
> <br>
> See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-February/218946.html<br>
> <br>
> =============== Diff against Tools-mt.1135 ===============<br>
> <br>
> Item was changed:<br>
> ----- Method: MessageTrace>>browseAllCallsOn:requestor: (in category 'actions') -----<br>
> browseAllCallsOn: selectorSymbol requestor: anObject<br>
> "Overwritten to modify the trace if the request origins from a model-menu command such as the message-list menu (shortcut)."<br>
> <br>
> + (((Preferences traceMessages and: [anObject ~= #button] and: [selectorSymbol = self selectedMessageName]) xor: Sensor shiftPressed)<br>
> + and: [self hasUnacceptedEdits not])<br>
> - (selectorSymbol = self selectedMessageName<br>
> - and: [ Preferences traceMessages ] and: [ self hasUnacceptedEdits not ])<br>
> ifTrue: [ self addParentMethodsSending: selectorSymbol ]<br>
> ifFalse: [ super browseAllCallsOn: selectorSymbol requestor: anObject ].!<br>
> <br>
> Item was changed:<br>
> ----- Method: MessageTrace>>browseAllImplementorsOf:requestor: (in category 'actions') -----<br>
> browseAllImplementorsOf: selectorSymbol requestor: anObject<br>
> "Overwritten to modify the trace if the request origins from a model-menu command such as the message-list menu (shortcut)."<br>
> <br>
> | selectorToBrowse |<br>
> selectorToBrowse := self selection<br>
> ifNil: [ selectorSymbol ]<br>
> ifNotNil: [ self getImplementorNamed: selectorSymbol asSymbol "since we can get passed literals"].<br>
> + (((Preferences traceMessages and: [anObject ~= #button]) xor: Sensor shiftPressed) and: [self hasUnacceptedEdits not])<br>
> - (Preferences traceMessages and: [ self hasUnacceptedEdits not ])<br>
> ifTrue: [ self addChildMethodsNamed: selectorToBrowse ]<br>
> ifFalse: [ super browseAllImplementorsOf: selectorToBrowse requestor: anObject ].!<br>
> <br>
> Item was added:<br>
> + ----- Method: MessageTrace>>browseMessagesFromButton (in category 'controls') -----<br>
> + browseMessagesFromButton<br>
> +<br>
> + self getSelectorAndSendQuery: #browseAllImplementorsOf:requestor: to: self with: #(button).!<br>
> <br>
> Item was added:<br>
> + ----- Method: MessageTrace>>browseSendersOfMessagesFromButton (in category 'controls') -----<br>
> + browseSendersOfMessagesFromButton<br>
> +<br>
> + self getSelectorAndSendQuery: #browseAllCallsOn:requestor: to: self with: #(button).!<br>
> <br>
> Item was added:<br>
> + ----- Method: MessageTrace>>optionalButtonPairs (in category 'controls') -----<br>
> + optionalButtonPairs<br>
> +<br>
> + ^ super optionalButtonPairs collect: [:spec |<br>
> + spec second<br>
> + caseOf:<br>
> + {[#browseSendersOfMessages] -> [spec copy<br>
> + at: 2 put: #browseSendersOfMessagesFromButton;<br>
> + yourself].<br>
> + [#browseMessages] -> [spec copy<br>
> + at: 2 put: #browseMessagesFromButton;<br>
> + yourself]}<br>
> + otherwise: [spec]]!<br>
> <br>
> <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220228/9daa5119/attachment.html><br>
> <br>
> <br>
<br>
On 2022-02-28T18:32:52+01:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:<br>
<br>
> 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>
> ---<br>
> Sent from Squeak Inbox Talk<br>
> <br>
> On 2022-02-26T18:13:10-06:00, asqueaker at 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"]<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220228/2a1a5997/attachment-0001.html><br>
> -------------- next part --------------<br>
> A non-text attachment was scrubbed...<br>
> Name: messagetrace-5.2.gif<br>
> Type: image/gif<br>
> Size: 297959 bytes<br>
> Desc: not available<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220228/2a1a5997/attachment-0001.gif><br>
> <br>