Simulator 3.0.x on macOS - Keyboard Shortcuts, Crank units, Ctrl-c

SDK Bug Reports
1

Behavior of Simulator on macOS changed in SDK v3.0.0.
It would be great if the old keyboard shortcuts and behaviors could be restored.
This was noted in the Changelog:

  • Simulator: Unified macOS Simulator with Windows and Linux. As a result some things will be slightly different

Specifically here's what I've noticed.

  1. I launch the simulator via the command line:
    "$PLAYDATE_SDK_PATH/bin/Playdate Simulator.app/Contents/MacOS/Playdate Simulator" whatever.pdx
    With <= 2.7.6 I can use ctrl-c to quit the Simulator from the terminal. On >= 3.0.0 this no longer works.

  2. The crank in simulator now uses minimum increments of 4 degree while previously it used 3.6 degrees. I ran into this yesterday with a bug which I hadn't noticed in the simulator because it was always reporting integer cranked degrees. It's better for developers to by-default see floating point values in simulator too. Maybe use 1.8 or 0.9 degree increments if you want something more precise than 3.6.

  3. Crank in simulator is now capped at a much lower value. In 3.0.x it reports +/- 4, 8, 12 degree changes (or occasionally 16/20) and all inertial scrolling events after the first one are 8 degrees. Previously this value was capped at 72.0 degrees not 8. (see playdate.getCrankPosition() can return 360.0 for example of previous behavior). On device this it is quite easy to turn the crank 180 degrees extremely quickly (<100ms), on Simulator 3.0.x this takes a minimum of 700ms (e.g. 180/8.0 == 22 events; 22 * 33ms/frame (30fps) = 726ms). And that's assuming a trackpad with inertial scroll. With a scrollwheel on my Logitech trackball/mouse it requires 5 distinct full scrolls and takes > 1second.

  4. A bunch of the keyboard shortcut changed. Specifically, many of the shortcuts are now option-X shortcuts, which is not very macOS-like. Even on Windows apps, few apps use bare alt-X because that is needed for menus (e.g. alt-f opens the file menu). I'm curious the reason for the change (was it unintentional?) -- I have muscle memory for the old cmd-X / cmd-shift-X shortcuts and would prefer these changes were reverted. Specifically:

a. Zoom toggle used to be cmd-2, now you can specify 1x, 2x, 3x zoom with option-1, option-2, option-3. Would love these to be cmd-1, cmd-2, cmd-3. Or cmd-0, cmd-2, cmd-3 (as reset zoom is cmd-0 in chrome, firefox etc).

b. Rotate used to be cmd-left / cmd-right, now it's option-left, option-right. This prevents option-left/option-right in text entry boxes (e.g. Console) for navigating words left / right. cmd-left / cmd-right would be preferred.

c. Device Info / Console / Lua Memory / Malloc Log
previously: cmd-d, cmd-shift-d, cmd-i, cmd-shift-i
changed to: option-d, option-y, option-m, option-l
What's the thinking here? Can we change it back please?

d. Help-> Inside Playdate / Inside Playdate with C
Was: cmd-shift-0, cmd-shift-1
Now: cmd-0, cmd-1
I think these were fine before with the shift modifier -- I was very confused when cmd-2 didn't toggle zoom in the new simulator, but even more confused when cmd-0/cmd-1 opened a web browser.

e. It used to be possible to toggle the crank/accelerometer drawer with cmd-shift-c. This is now impossible with keyboard or view menu. It would be nice if this functionality was restored so doing this didn't require a mouse.

All of the above were tested against 3.0.1. As a workaround it possible to manually remap all of these (except the crank drawer) using the macOS keyboard controls but I'm sure other devs are similarly impacted.

Thanks!

2

Thanks for the feedback.

I’m not 100% sure why ctrl-c no longer works to quit the sim from the terminal, that’s an odd one.

To increase/decrease the crank speed you can hold the shift (faster) or option (slower) keys while scrolling the mouse. While the default is slower than before, it still seems fast enough for most testing, especially with modifiers. The UI framework we’re using doesn’t support inertial scrolling which makes it tricky to ‘flick’ the crank as you could before, I’ll investigate that more.

As for floating point results from the crank, you can get them from holding option, but it seems unnecessarily fussy to be returning factional values in all cases and a bit unexpected from a pixel based control. I do understand why you might want them for testing however.

I agree some of the keyboard shortcuts aren’t very Mac-like and have adjusted some of them.

3

option-scroll does not trigger floating point inputs, it uses still uses 2.0 degree steps. for the crank. Similarly the input field only shows/accepts integers (old simulator supported floats), so that cannot be used either. It is possible to grab the circle in the crank tray and this will get you into floating point vales. On device callback events are ~0.20. So it's possible to have a high-skill ceiling requiring 1 degree precision. I'll use the click-and-drag in the crank circle in the drawer in the meantime.

Thanks for taking a look at the other stuff.

4

After looking at it closer option only halves the value, if the value is even it will still be an integer value. I just implemented control-c (sig int) handling so that should be good to go for 3.0.2.