" Unhandled Darwin event" on OSX Yosemite about jnativehook

[kwhat]

Hi,

It sounds like you compiled with the ant.build.debug property set to true which enables the hook for all events, even if the lib doesn't use them. Event 0x1D (29) looks like it might be some kind of tablet event that is just ignored at this time. Future support maybe added.

Do you get other log messages or exceptions when the hook starts? Try setting the log level to all. Accessibility needs to be enabled but should throw an exception.

-Alex

[aterjung]

Hi,

thank you for your fast response! I tried to start the demo without compiling directly from the pre-compiled jar with java -jar JNativeHook.jar, getting the same result. (I have to enable the accessibility features, then restart again). The First waring is:

jni_SetProperties [146]: Invalid result returned from hook_get_pointer_acceleration_threshold()!

then i will geh the Unhandled Darwin event messages for every touchpad movement. I can't see any response to keyboard or touchpad events in the demo.
As far as i can see, the logger is set to ALL.

thanks in advance

[danielboros]

I am also on Yosemite and can confirm that the demo code does not trigger the event methods and outputs Unhandled Darwin event! for touchpad movement on RC3.

Wonder what changed between 10.9 and 10.10?

[aterjung]

is this probably connected with this change in 10.10?

App Sandbox

Impact: An application confined by sandbox restrictions may misuse the accessibility API

Description: A sandboxed application could misuse the accessibility API without the user's knowledge. This has been addressed by requiring administrator approval to use the accessibility API on an per-application basis.

CVE-ID

CVE-2014-4427 : Paul S. Ziegler of Reflare UG

[kwhat]

@danielboros Does RC2 work?

@aterjung I don't have hardware that can run 10.9 or 10.10 at the moment.

[aterjung]

i just tried RC2 instead of RC3 an everything is fine ;-) Can I do anything to fix the bug in RC3?

[kwhat]

I can confirm the same.

[kwhat]

83e5d70 should fix the issue. it is related to the logger and the native thread not being attached.

[danielboros]

Works for me as well, thanks for the quick fix!

[RaiMan]

built from the latest sources of branch master, but still get the "Unhandled Darwin ..." warning on Mac 10.10.1 when running the demo.

BTW: setting the Level to OFF does not do anything. the warnings are still displayed.
How to switch off logging in the demo?

One more thing:
tried to switch off the mouse move listener in the demo using
menuItemMotionEvents.setSelected(false);
in WindowOpened(), but at startup the item in the menu is still selected.
How to switch off the listener before startup?

[kwhat]

@RaiMan The Warning for the unhandled event is due to the null input event on that platform. You will need to compile with ant.project.debug=false to prevent listening for that particular event.

The logger implements Java's bundled logging API. There are a number of ways to configure their logger. The preferred way is through the logger.properties at the application level. You should be able to specify the org.jnativehook package to target the library specifically. The code below is from the demo and will allow you to set the log level at runtime using a quick and dirty method. logger.setLevel sets the level for the logger and handler.setLevel sets the level for the specific handler. You can attach several handlers to a logger at various levels. For example, the console logger can be set to the warning & error level while a file logger can be set to info and a network logger can be set to all.

        // Disable parent logger and set the desired level.
        logger.setUseParentHandlers(false);
        logger.setLevel(Level.ALL);

        // Add our custom formatter to a console handler.
        ConsoleHandler handler = new ConsoleHandler();
        handler.setFormatter(new LogFormatter());
        // Change Level.WARNING to the desired Level.  Level.OFF will disable all of it.
        handler.setLevel(Level.WARNING);
        logger.addHandler(handler);

As far as the listeners go, you cannot disable particular input types at the hook level. You can only ignore the delivery of the events. In the demo, events are removed from the GlobalScreen listener on when an itemStateChanged event matching the correct criteria is delivered for the menu item. See the method with the same name in the demo.

[RaiMan]

thanks for the quick feedback (as always :-)
I will work through your comment and think my question will turn out to be answered.

I plan to use jnativehook in version 1.2 of SikuliX (https://github.com/RaiMan/SikuliX-2014)

[kwhat]

Should be fixed in the RC4 build I just posted. Enjoy :)

[kwhat]

@RaiMan NP, I just took a look at SikuliX and you seem to know a bit more about maven than I do. Would you mind having a look at #5? I am not sure I understand the question. Does he want a pom file? Would something like the following satisfy that requirement? Thanks in advance!

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.jnativehook</groupId>
  <artifactId>JNativeHook</artifactId>
  <version>1.2.0</version>
</project>

[RaiMan]

Just had a look at the post and made the mentioned solution available directly in the post, being a possible solution to use JNativeHook in Maven projects.

If you want to use the "cleaner" solution and install JNativeHook in your normal local Maven repo, you need to setup a minimum pom.

I do not think, that you should publish a pom currently, since:

• your project currently is not mavenized at all and might lead people on a wrong track
• there is a solution with a special repo available now at #5
• if someone wants it in his normal Maven repo, he should know how to do it

To think about mavenizing your project at all only makes sense, if you plan to publish on MavenCentral in the future (what generally is a good idea for any Java stuff, that is intended to be used as some library).

But to get there with your current project structure and build process is a challenge.
On some less critical level I have a similar problem with some native stuff in SikuliX, that I solved with prebuilt libs for Windows, Mac and Ubuntu, but I am not yet on MavenCentral but only one step before at OSSRH.

Conclusion: I do not recommend to invest in any Maven stuff in the moment, if you have other issues to tackle or ideas for feature improvements. If you decide to switch to a MavenCentral compatible build process, it might be worth to have a look at Gradle. I will switch to it next year.

[kwhat]

Apparently I didn't fix this correctly.

[kwhat]

Should be addressed @ cc13af6 by reducing the log level from warning to info.