Detecting keypresses on Mac OSX Catalina

[Celtic Minstrel]

I'm having issues with detecting certain keypresses when building on Mac OSX Catalina. The system seems to think that the application wants to be able to monitor input while in the background, which isn't even true.

According to another post I found on this forum (quoted below), it's caused by using IsKeyPressed, and the solution is to use events. But that's not possible – I'm trying to do is handle modified mouse clicks (eg, Alt+Click) and scroll wheel (eg, Ctrl+Wheel). The MouseButtonEvent does not have a modifier key field, so the only option is to manually check for the modifier. The same applies to the scroll event.

I know for certain that other apps can handle modified mouse clicks and scroll wheel without needing to register for input monitoring in System Preferences, so why is it that there's no way to do this in SFML? If IsKeyPressed does not work, what other options are there? Perhaps the Mac implementation of IsKeyPressed is incorrect.

If you actually use events and not real-time input (sf::Keyboard::IsKeyPressed), then things should work fine.

For real-time input you will have to grant the app input monitoring privileges as far as I know, that's one of the major changes in Catalina for all applications.
There are ways to disable some stuff for developers, but as I am not a macOS user, I don't really know and would need to research myself.

EDIT: Based on the contents of the framework package, I appear to be using version 2.5.1.

[eXpl0it3r]

Ctrl and Alt also generate key events. You can track the state of the keys (key pressed/released) with variables and look it up during a click event.

The monitoring permission request is a security feature of macOS and nothing we can or should be able to workaround. With isKeyPressed you can get key inputs from any application, thus essentially building a key logger, which is why macOS decided to require monitoring permission for that part of the API.

[Celtic Minstrel]

Ctrl and Alt also generate key events. You can track the state of the keys (key pressed/released) with variables and look it up during a click event.

So that's really the only way, is it?

It would be great if a future version added modifiers to the mouse events though, to support this use-case. Apparently the underlying Cocoa events already contain that information. (No idea about the equivalent on other operating systems though.)

The monitoring permission request is a security feature of macOS and nothing we can or should be able to workaround. With isKeyPressed you can get key inputs from any application, thus essentially building a key logger, which is why macOS decided to require monitoring permission for that part of the API.

I get that theoretically that could be used in such a way, but I think it could've been built in a way that didn't trigger the monitoring permission… even if it meant doing exactly what you just said internally to SFML.

Still, perhaps if mouse modifiers were supported, there would no longer be any need to use isKeyPressed.

[Celtic Minstrel]

Ctrl and Alt also generate key events. You can track the state of the keys (key pressed/released) with variables and look it up during a click event.

This works perfectly for the modifier keys. However, it turns out I also need to detect chords composed of arrow keys, yet for some reason no other key besides the modifiers ever sends a KeyReleased event. Am I doing something wrong?

[eXpl0it3r]

Arrow keys work just fine with events. Make sure your modifier detection code isn't consuming the event before it hits your other key event handling.

One thing to also keep in mind, since you used the words "chords", that many (cheap) keyboards can't handle more than 3-4 key presses at a time, usually depending on certain blocks of keys.
You'd need to have a keyboard n-key-rollover support, if you want to not have such a limitation.

[Celtic Minstrel]

Arrow keys work just fine with events. Make sure your modifier detection code isn't consuming the event before it hits your other key event handling.

I can't see any way that that could be the case. My main loop is literally this (the parameter is passed by reference):

while(window.pollEvent(currentEvent)) handle_one_event(currentEvent);
 

And just to test if maybe you were right, I added this as the very first thing in handle_one_event, before my modifier detection code (which does swallow some key events):

if(event.type == sf::Event::KeyReleased) {
        std::cout << "A key was released!\n";
}
 

And I see the message if I press and release a modifier key, but not if I press and release any other key.

That said, I tried opening up a different project and it works in that project, so there must be something I'm doing somewhere that makes it stop working…

One thing to also keep in mind, since you used the words "chords", that many (cheap) keyboards can't handle more than 3-4 key presses at a time, usually depending on certain blocks of keys.
You'd need to have a keyboard n-key-rollover support, if you want to not have such a limitation.

That shouldn't be a problem, I'm only looking for 2 arrows at a time.