This is basically not possible for security reasons (on at least macOS), but you can do it sort of, still, at least as root/superuser.
This has historically been possible on all platforms, but unlike reading from the keyboard, waiting until pressing enter, which is possible (through use of C library), it’s not possible to portably monitor the keyboard, with C, and thus neither any other language.
But since the julia runtime is different for each platform, I actually thought maybe Julia could provide the non-portable code for this, i.e. provide a portable API for Julia (source) code apps (which would call the non-portable platform APIs). And maybe that it should. This could also be done through a package, but I thought an argument could be made for Julia to do it, for discoverability, to avert also that people would use non-portable e.g. Windows APIs, and tie their Julia (otherwise portable) source code to one platform.
For now I don’t know of any Julia package to do this but you can use others, e.g. this Python package I found, through PythonCall.jl. There are basically no great disadvantages (this is not speed-critical). It’s
LGPLv3-licenced which is good for basically everything, unless you have some “GPLv2-only code” to use with.
You might look at how pygame handles this to steal some ideas.
[There is a port of it, to Julia, GameZero.jl, available. Both use the SDL C library, and it likely handles, but not for terminals, rather (full-screen) windows?]
Recent versions of macOS restrict monitoring of the keyboard for security reasons. For that reason, one of the following must be true:
- The process must run as root.
- Your application must be white listed under Enable access for assistive devices. Note that this might require that you package your application, since otherwise the entire Python installation must be white listed.
- On versions after Mojave, you may also need to whitelist your terminal application if running your script from a terminal.
Please note that this does not apply to monitoring of the mouse or trackpad.
You can see there details for Linux and Windows. Obviously monitoring the keyboard is possible somehow, e.g. for games or simply for word processors, i.e. GUI apps, and while games may not be the traditional GUI-type, I assume they use the same platform GUI APIs, mostly. I.e. they function as if they were in a windows, but they can in many or most cases be full-screen. Then I don’t really see a security issue. It is I think about when you have many apps on screen (or even hidden with no visible window), why should all be able to monitor the keyboard? A keylogger is a known security risk, monitoring and logging e.g. all your passwords.
Since there is no risk, nor forbidden to monitor the mouse, maybe that is good enough for you? Ideally you would have a button on screen (requires Gtk.jl or other GUI toolkit?) to press. It’s likely no what you want that you simply press a button on the mouse and it triggers something in your app whereever the mouse pointer is located, in or out of your window.
At least in some Linux GUIs you can type into a window only when it has focus, and only when the pointer is over your window. It seems like less of a security risk, also would be annoying if you couldn’t type anything elsewhere without a q…