Currently using the XLib and XInput2 requires the overhead of installing the required lib to generate the headers which does not let non-linux host or one without these libs to build the project for those platform.
Second most important thing is that where there is non-X11 desktop environment the library won't work. Which limits it in the amount of targets.
Future plan is to migrate all the c-interop generated stubs into dlopen/dlsym/dlclose Posix API which allows to dynamically fetch the CPointer<CFunction<*>> and invoke it. Which can be done in the runtime (and has pretty less runtime overhead), we may even cache it at the first access.
This will let the library to be build without headers and in Windows/Mac for Linux as well and and can easily test it remotely on a VM. This will also enable to fallback to the Linux device API (/dev/uinput | /dev/input/xxx) if X11 is not present, which will allow the lib to support almost all the linux platforms (though this device API requires superuser).
Currently using the XLib and XInput2 requires the overhead of installing the required lib to generate the headers which does not let non-linux host or one without these libs to build the project for those platform.
Second most important thing is that where there is non-X11 desktop environment the library won't work. Which limits it in the amount of targets.
Future plan is to migrate all the c-interop generated stubs into dlopen/dlsym/dlclose Posix API which allows to dynamically fetch the
CPointer<CFunction<*>>
and invoke it. Which can be done in the runtime (and has pretty less runtime overhead), we may even cache it at the first access.This will let the library to be build without headers and in Windows/Mac for Linux as well and and can easily test it remotely on a VM. This will also enable to fallback to the Linux device API (
/dev/uinput
|/dev/input/xxx
) if X11 is not present, which will allow the lib to support almost all the linux platforms (though this device API requires superuser).