Consider using another IO Library

[casaout]

It seems that https://github.com/wilix-team/iohook is no longer maintained.

So we could create our own fork, contribute to an existing fork, or consider using another library (e.g. uihooki-napi)

We might also want to create a build for arm on macOS.

[casaout]

Comment from @melihcatal

[regarding the uihook-napi], I saw that one as well. But the point is using npm install for the iohook is not sufficient for the arm processor. Because some of the files are ignored by the npmignore . Instead if we need to clone the repo and manually build it , then its possible to build for the arm processor. You can see the issue here: wilix-team/iohook#400 .

And iohook uses prebuilt releases to download the release instead of building it from scratch.Once arch , platform and target are defined ihook checks the github releases page to see if this config setting has already been created. The page is: https://github.com/wilix-team/iohook/releases/tag/v0.9.3 If so iohook downloads and uses that one. Unfortunately, there is no prebuilt version for arm processors.

So I forked the repo, updated npmignore file and build iohook for the arm arch. Then I released them on github: https://github.com/melihcatal/iohook/releases/tag/v0.9.3 . And finally I updated the dependency accordingly so the code looks for the forked releases page instead of the original one. I wrote a bit long, but I wanted to clarify the changes. Also I'm not sure if this is the best/correct approach since this is my first experience with the electron and m1 stuff. What do you think about this solution ?

[regloff]

I created a fork of the UserInputTracker to try out the library you suggested. It works and the listeners and types are the same as in iohook. Let's discuss this afternoon how we should proceed here.

[regloff]

It doesn't work all the time in the context of FlowTeams. Sometimes, after starting the application, no keyboard/mouse events are received by the tracker (at least on Mac). After restarting the application, the tracker works again.

We have to invastigate this issue further.

[regloff]

With release 0.4.15, FlowTeams switched from iohook to a patched version of uiohook-napi. In the following, I will document some things we had to consider:

• uiohook-napi works very similar to iohook and is still maintained. However, the maintainer has no access to macOS.
• By switching to this new library, we were able to update several dependencies. Most notably, we were able to update Electron from version 11.5.0 to 15.5.5.
• There exists a known issue that the library might crash in combination with Electron on Mac. The issue comes from the underlying C library, which has to deal with listeners that stop working from time to time. However, their fix crashes uiohook-napi somehow. To circumvent this issue, we created a fork of the library, removed the breaking part and created a workaround: Whenever no io-activity is detected, but it seems that the user is still working, the input tracker is automatically restarted.

While the implemented solution is definitely not ideal, it seems to be the best solution at the moment. Maybe there will be a more reliable library in the future.

[casaout]

In SnosMe/uiohook-napi#23 (comment), someone recommended to use https://github.com/robotn/gohook instead, but it's written in go.

[casaout]

• The uihook-napi library was recently updated, citing changes in the C library. Maybe this fixes the macOS-issues. Not sure though, if it allows builds for arm-processors. The problem is that the main maintainer doesn't own a macOS-device.
• From reading through some discussions, the iohook-library has less issues on arm-based MacOS processors, but was not released for quite a while, even though a pull request to bump support to node 18/19 and electron 18/19 exists. Are these updates for supporting newer versions small enough that we should just consider creating a fork?
• Maybe a better, more frequently updated library exists?