Map "Command" to Amiga keys do not work under workbench

[nicolasbauw]

Ctrl-A-A works to reset the Amiga, but Amiga-E does not open "execute command" dialog under workbench, for example. Test with 3.2 ROM and WB.

[idrougge]

Did you use the left or right Amiga key?

[nicolasbauw]

I tried with both 😉 On the vAmiga virtual keyboard, it works with right amiga. On a real machine, If I remember it’s left amiga (can not try right now to be sure, had to pack my machines last year after flood damage. My memory can be wrong.)

[idrougge]

All the usual commands on a real Amiga use the right Amiga key.

[mithrendal]

https://github.com/keirf/amiga-stuff/releases/tag/testkit-v1.20

Please double check the issue with the keyboard test in amitestkit. If it is wrongly mapped you should be seeing this on the keyboard layout in the keyboard test screen.

[dirkwhoffmann]

Confirmed. When the Cmd keys are mapped directly to the Amiga keys, a key combination Amiga+key is not recognized if key is a standard character.

[dirkwhoffmann]

@nicolasbauw Are you on macOS Ventura? I can only reproduce the issue on my Ventura machine. It works flawlessly on Monterey.

[nicolasbauw]

I'm on Monterey 12.6

[dirkwhoffmann]

It's some permission issue. I got it to work on Ventura by explicitly granting vAmiga keyboard permission in one of the system setting dialogs:

To test inside vAmiga, simply open the virtual keyboard from the menu or by hitting Cmd-K. The keyboard will appear in a separate window and display every pressed key in real-time.

[nicolasbauw]

Yesterday, when I started to use the "Map command to Amiga keys", indeed I had to grant some permissions:

This one was already set:

The key test recognizes left and right Amiga keys pressed alone, but not when pressed with another key. That works well with shift, for instance.

The keyboard will appear in a separate window and display every pressed key in real-time.

Well, that does not happen. No key press has effect on virtual keyboard. But apart the problem mentioned, my keyboard works well in vAmiga. I did not find some other place where a permission could miss.

[dirkwhoffmann]

Well, that does not happen

Here is a small video showing how it looks here. The virtual keyboard (if opened as a separate window) reflects what I type on the keyboard:

https://user-images.githubusercontent.com/12561945/200183700-216adc66-bd05-4605-8452-6b75a66287a8.mov

With correct permission set, the Amiga key is working (as can be seen in the video). However, Apple's permission system is a mess. Sometimes I had to remove vAmiga and add it again, because macOS has trouble distinguishing different instances of the same app. Moreover, there seem to be multiple permission dialogs (at least in Ventura).

I am thinking about solving this issue by removing the direct mapping feature altogether. Everything that requires extra permissions is a nightmare in macOS and it becomes worse with every new macOS release. I had a similar situation with sandboxing which drove me mad until I switched it off.

[idrougge]

FS-UAE manages to handle the cmd key without such permissions, so perhaps it is not needed?

[nicolasbauw]

Ok, my bad, I tried the virtual keyboard with the virtual keyboard focused, not the emulator focused. But, the behavior is similar, even after remove / reset permissions : the Amiga keys alone work, but not with another key.

I think I found what happens : in fact, it looks like "map command to Amiga keys" work ONLY for ctrl-a-a (at least in my case) , as (for instance) Command-R reboots the Amiga (like the menu shortcut) : with another key pressed, command is not mapped to the Amiga, but is still acting like a regular "command" press in MacOS.

[dirkwhoffmann]

Both Cmd keys send Cocoa events that can be catched via

func flagsChanged(with event: NSEvent) 

Thus, recognizing these keys is easy.

The problem is that the CMD key still triggers side-effects (e.g., CMD-H hides the window) and the side-effects are processed by macOS before my app is even told about it. The current approach is to install an event trap deep down in the system which filters out the CMD flag. This works because the event trap is called before special combinations such as CMD-H are processed. The drawback of this approach is that installing event traps requires extra permissions (which makes sense because it's the ideal place for a key tracker). To handle the CMD key without extra permissions, the only chance I see at the moment is to remove all key-equivalents in all menu items (i.e., to remove all possible side effects). In FSUAE it's a little easier, because it is not a real Cocoa app (e.g., there are no standard macOS menus).

[dirkwhoffmann]

I've found a nice solution. Based on what is explained here it's possible to subclass NSApplication and overwrite function sendEvent(_ event: NSEvent). The function is invoked early enough in the command chain to reroute any key event carrying the CMD tag. This code here does the trick:

@objc(MyApplication)
class MyApplication: NSApplication {

    var disableCmdKey = false

    override func sendEvent(_ event: NSEvent) {

        if disableCmdKey {

            if event.type == NSEvent.EventType.keyUp {

                if event.modifierFlags.contains(.command) {

                    debug(.events, "keyUp: Removing CMD flag")
                    event.cgEvent!.flags.remove(.maskCommand)
                    super.sendEvent(NSEvent(cgEvent: event.cgEvent!)!)
                    return
                }
            }
           ...
        }
        super.sendEvent(event)
    }
}

There is no need for an event tap any more which means that vAmiga won't need extra permission in the future.

[dirkwhoffmann]

All the usual commands on a real Amiga use the right Amiga key.

In the next version, it'll be possible to map both Cmd keys individually. E.g., if the right Cmd key is configured to control the Amiga, the left Cmd key is still available to control the Mac.

[dirkwhoffmann]

Fixed in v2.2b1