<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Christoph --<div><br></div><div> -1</div><div><br></div><div>Keyboard interactions should not force the user to figure out where the mouse cursor currently is.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
<p style='color: #AAAAAA; margin-top: 10px;'>Am 23.08.2021 17:05:19 schrieb commits@source.squeak.org <commits@source.squeak.org>:</p><div style='font-family:Arial,Helvetica,sans-serif'>A new version of ToolBuilder-Morphic was added to project The Inbox:<br>http://source.squeak.org/inbox/ToolBuilder-Morphic-ct.278.mcz<br><br>==================== Summary ====================<br><br>Name: ToolBuilder-Morphic-ct.278<br>Author: ct<br>Time: 23 August 2021, 5:05:03.885565 pm<br>UUID: 11672978-6add-0747-a391-a7bb517eb028<br>Ancestors: ToolBuilder-Morphic-mt.277<br><br>Proposal: When #openToolsAttachedToMouseCursor is enabled, always open tools under the hand.<br><br>I have been trying out this patch for several months in my image and overall found it very convenient for a number of reasons:<br><br>1. It feels much more familiar if tools *always* open under hand, not only sometimes (following some kind of, maybe non-straightforward, heuristic). The former #currentEvent hack was a nice idea but eventually, such as distinction was less intuitive for me.<br><br>2. The former #currentEvent hack does not always work: Already some time ago, I experienced a small number of situations where - after triggering a tool via keyboard - #currentEvent sent from #openAsTool already answered a newer mouse move event (maybe a threading issue? I never managed to trace this down). A more significant observation is that since #currentEvent is implemented as a dynamic variable [1], its return value is not always the same as the latest user event. You can see this in effect when you do-it the following via keyboard before loading this patch:<br><br> self inform: #foo.<br> Workspace open.<br> <br>(In this situation, one could argue that not opening the workspace under the cursor would be the right behavior because there is no current mouse event on the stack at this moment, but my intuition does not think so.)<br><br>3. If you have this preference enabled, you are probably a mouse user, and your next action after opening the tool will most likely be a mouse action anyway. Thus initially having the tool under hand does not harm, but it is a nice utility because you can immediately control the spatial arrangement without extra effort.<br><br>[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-September/211392.html<br><br>=============== Diff against ToolBuilder-Morphic-mt.277 ===============<br><br>Item was changed:<br> ----- Method: SystemWindow>>openAsTool (in category '*ToolBuilder-Morphic-opening') -----<br> openAsTool<br> "Open this window as a tool, that is, honor the preferences such as #reuseWindows and #openToolsAttachedToMouseCursor."<br> <br> | meOrSimilarWindow |<br> meOrSimilarWindow := self openInWorldExtent: self extent.<br>+ Project uiManager openToolsAttachedToMouseCursor<br>- (Project uiManager openToolsAttachedToMouseCursor<br>- and: [ | event |<br>- event := self currentEvent.<br>- event isMouse and: [event isMouseUp]])<br> ifTrue: [<br> meOrSimilarWindow setProperty: #initialDrop toValue: true.<br> meOrSimilarWindow hasDropShadow: false.<br> self currentHand attachMorph: meOrSimilarWindow].<br> ^ meOrSimilarWindow<br> !<br><br><br></div></blockquote>
</div></body>