Once you’re done picking over KeyBufferer I need to change that isPopupTrigger to SwingUtils.isLeftMouseDown. Or you can.
I cherry-picked in the relevant parts of 13126. Try 3.3.2-test2.
3.3.2-test2 fixes the touchpad Ctrl+Leftclick context menus on Macbook Pro for me (no longer deselects the target, so the option I pick works correctly). To be clear that doesn’t restore 3.2.17 functionality (which I believe was, inappropriately-to-Mac, for Command+Leftclick to bring up the context menus), but it does restore functional context menus (for me at least).
Meanwhile there is presently no way (on Mac touchpad) to toggle a piece in/out of a selection (what on other systems we do with Ctrl+Click). I think I wrote up in one of these threads “what 3.2.17 did on Mac” and “what we actually ought to do on Mac”, if you need reference.
Brian
So, correct me if I’m wrong here:
3.3.2-test2 fixes the touchpad Ctrl+Leftclick context menus on Macbook
Pro for me (no longer deselects the target, so the option I pick works
correctly). To be clear that doesn’t restore 3.2.17 functionality (which
I believe was, inappropriately-to-Mac, for Command+Leftclick to bring up
the context menus), but it does restore functional context menus.
This sounds like what we want for 3.3.2.
Meanwhile there is presently no way (on Mac touchpad) to toggle a piece
in/out of a selection (what on other systems we do with Ctrl+Click). I
think I wrote up in one of these threads “what 3.2.17 did on Mac” and
“what we actually ought to do on Mac”, if you need reference.
This also sounds like what we want for 3.3.2. It’s no change from
3.2.17 (or earlier) so makes nothing worse. We should fix this in 3.3.3.
–
J.
On first paragraph, yes, I think it’s satisfactory and excellent for 3.3.2. (and it’s definitely what we want for 3.3.3)
On second paragraph, it is a change from 3.2.17 (in that version, with the Control and Command keys “fully swapped”, you could toggle things in and out of selection). Here (present 3.3.2) we’ve got the Control swapped back to where it’s “supposed to be” on Mac, but we don’t have a selection toggle any more. But I’ll certainly agree that it “might be good enough for the length of time we expect 3.3.2 to be the current version”.
Thus spake Cattlesquat:
On first paragraph, yes, I think it’s satisfactory and excellent for
3.3.2. (and it’s definitely what we want for 3.3.3)
Great.
On second paragraph, it is a change from 3.2.17 (in that version, with
the Control and Command keys “fully swapped”, you could toggle things
in and out of selection). Here (present 3.3.2) we’ve got the Control
swapped back to where it’s “supposed to be” on Mac, but we don’t have a
selection toggle any more. But I’ll certainly agree that it “might be
good enough for the length of time we expect 3.3.2 to be the current
version”.
Ah, ok.
Where is the code which does that?
–
J.
This is in KeyBuferrer.mousePressed(), right?
For the map it’s KeyBufferer.mousePressed.
I’m having a hard time keeping in my head what the standard Mac behavior is and what we’re doing now.
Command + Click should toggle selection, yes? And SwingUtils.isControlDown() checks for Command on a Mac now. So… why doesn’t selection toggle work?
Here’s the theoretical spec:
Old Mac Interface up to and including 3.2.17
(1) Context Menu: Command + Left Click on e.g. a piece brought up context menu
(2) Selection Toggle: Control + Left Click did NOT bring up a context menu
(3) Shortcut Keys: Shortcut Keys for doing things on a piece tend to be activated by CONTROL + C (NOT activated by COMMAND + C)
Proper Mac Interface (3.3.3+)
(1) Context Menu: CONTROL + Left Click brings up a context menu.
(2) Selection Toggle: Command + Left Click, by contrast, should toggle a piece in and out of the current selection
(3) Shortcut Keys: COMMAND + C (and other letters and combos) should typically activate the shortcuts on pieces, CONTROL should not.
Temporary Mac Interface (3.3.2)
(1) Context Menu: CONTROL + Left Click brings up a context menu.
(2) Selection Toggle: Toggle selection… … Control? Command? (Command seems unused for anything else in 3.3.2, so maybe safe?)
(3) Shortcut Keys: Shortcut Keys remain Control + C for now
IN ALL SPECS
You can also bring up context menus by right+clicking (if have a two-button mouse, or if you have your touchpad set up for clicking-with-two-fingers is a right click or clicking-in-right-corner is a right click or whatever)
Brian
p.s. Haha yes I completely agree, it is screwing with my mind, our posts actually collided.
p.p.s. Edit - cleaned it up a bit, put things in the same order in each spec.
Okay that part is indeed a bit mystifying. If I browse into the release branch on github, will KeyBufferer.java show the “current 3.3.2 code” now? Ideally point me at somewhere I can browse what code is running now in 3.3.2.
Thus spake Cattlesquat:
“uckelman” wrote:
Command + Click should toggle selection, yes? And
SwingUtils.isControlDown() checks for Command on a Mac now. So… why
doesn’t selection toggle work?Okay that part is indeed a bit mystifying. If I browse into the release
branch on github, will KeyBufferer.java show the “current 3.3.2 code”
now?
Yes, as of just now. (I pushed 30 seconds before writing this.)
–
J.
Ah, will check. By the way, at least for 3.3.3 it is possible that getMenuShortcutKeyMask() will be useful: stackoverflow.com/questions/810 … 44#8105344
Returns “Meta” for Mac, “Ctrl” for Windows etc.
Oh, hang on, I think I figured it out.
No, no. I haven’t.
I’m getting suspicious of line 121 - SwingUtils.isRightMouseButton(e) ||
Because the part that currently “isn’t happening” is the part where I click-on-a-target, and in this case I’m Command+LeftClicking the piece I want to add to a selection. I bet “isRightMouseButton” isn’t currently returning true on mac for “Command+LeftClick” (Because of course it SHOULDN’T in 3.3.3, God Help Us All)
Clearly as we move toward 3.3.3 we ought to try to unwire some of the mind-fuckery from this –
SwingUtils.isContextMenuDown() – True for “plain Right Click” and for “Control+Leftclick on Mac”
SwingUtils.isShortcutKeyDown() – (Command for Mac, Ctrl for everybody else)
SwingUtils.isSelectionToggle() – True for “Ctrl+Leftclick” for most systems, “Command+Leftclick” for Mac.
Because trying to look at “isControlDown()” and remember when it actually-isn’t-Control, I think is giving us both headaches already.
Just checking: On point (1) in both specs … this simultaneously selects the piece, right? And will de-select the previous piece, unless SHIFT is pressed? That is the left-click behaviour (ie what happens with two-finger trackpad press on a default Mac setup).
Point (2) 3.3.3 spec - yes, that is “proper” Mac behaviour.
Point (3) shortcut keys. In support, to quote from Apple HI guidance, the developer should “Prefer the Command key as the main modifier key in a keyboard shortcut. The Command key is used extensively as the main modifier throughout the system, so users know it well. It’s also positioned for quick access while typing.” It goes on to discourage Control because it is used extensively by MacOS. Given all that, simply swapping interpretation of Control and META on MacOS might be the fix but recognising that this has implications for module documentation, though this will be an issue that many Mac users will be familiar with.
It is also worth referring module developers to that link. There are some useful considerations to make when choosing command keys.
And yeah, it’s line 121 (and its ilk where selection would be cleared) – “isRightMouseWhatever” gets a special Mac case in SwingUtils for the Control key but it does not currently get one for the Command key.
Correct.
Yes, finally got a handle on that. Now we’re just trying to Frankenstein some temporary measure together for 3.3.2.
Yeah what the plan for 3.3.3 is, is we need to make it so that when module designers on e.g. Windows and Linux make a module shortcut e.g. Ctrl+C, that this is automatically translated to Command+C when running the same module on a Mac. And likewise when a Mac-based module designer implements Command+C shortcut, it is automatically turned into Ctrl+C for Windows and Linux users. Obviously that implementation, while the correct multi-platform approach, requires “a bit deeper surgery” and so that’s why we’re trying to stabilize things with 3.3.2 so everybody can have a version that at least “works about as well as 3.2.17 but now with HiDPI monitors fixed, and Macs made no worse than before”, so that we can have time to work on 3.3.3 and make things “nice”.