Since KBGetLayoutType and LMGetKbdType are Carbon APIs, although not yet deprecated, is it okay to use them for Mac App Store distribution?

I just emailed you the details. I think you’ll find it interesting. let myEmail = "rakic" + "@" + "me.com"

You’re a legend. Amazing as always. Thank you.

Of course.

They won’t. The highest voted solution is quite inelegant since it’s hardcoding strings, and my app is localized in numerous languages. I would need to find the menu names for each language and then match the strings. The other, where someone suggested using UIMenuBuilder – that API isn’t available on macOS, and I’m not using Mac Catalyst.

Filed under FB13324789, FB13324866, and FB13324935.

There’s a reason I emphasized “while maintaining the system’s dynamic, contrasting border.” The solution you linked to, like every other one on the web, does not provide a window border that masks to the containing view.

I’m talking about inner rim stroke that almost every window, popover, menu, etc. in the system has. This stroke is more apparent in dark mode.

I also tried using IOKit.hid directly, but that didn’t help either. Nor did info available here: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html

Slight correction: .maskSecondaryFn is 0x800000 (NX_SECONDARYFNMASK / kCGEventFlagMaskSecondaryFn / NSFunctionKeyMask / 8388608). But simulating 0xFF00000003 key press on mouse click still stands as the goal.

I remapped two hardware keys using the IOHIDEventSystemClient API to ones corresponding to the Fn (Globe) and then manually tested their behavior. The 0xFF0100000030 is equivalent to kHIDUsage_AppleVendorKeyboard_Language, part of the AppleVendor Keyboard Page (0xff01) usage page, and the 0xFF00000003 is equivalent to kHIDUsage_AV_TopCase_KeyboardFn, part of the AppleVendor Page Top Case (0x00ff). Reference: Apple’s official HID usage tables