Updates to Eventtap and Question

[asmagill]

Not knowing how many people prefer getting their info here versus tracking the issues on Github, I'll throw this out here as well just to see..

I am working on some updates to the hs.eventtap  module to provide at least some access to the NSEvent object corresponding to the CGEvent objects eventtap currently tracks. This opens up the possibility, I think (it looks promising, but I'm still in early stages), to capture additional things like the special media/brightness keys on laptops and maybe some basic gestures on the trackpad/magic mouse... nothing as fancy as capturing custom gestures (yet?) but at least the built in ones, and maybe more...

The main question I have right now is this:  the event types "tapDisabledByTimeout" and "tapDisabledByUserInput"... as far as I've been able to find, these are basically notifications by the OS that it's disabling the eventtap for some reason -- because of slow response, memory pressure, etc.  You don't even have to add them to your eventtap's list of desired events (in fact doing so results in a compile time warning of a negative shift... not sure what our runtime inclusion does... probably ignores them?) -- they always come through to the callback whether or not you request them.  So, I'm thinking they should be silently handled by the eventtap code (i.e. re-enable the tap) and silently discarded -- the lua callback function couldn't really do anything else with them anyways.  Agree? Disagree? Know more about them then I do at the moment?

If I do move to handle them internally, is anyone currently employing code that would need to change because they disappear from the types table or don't invoke the lua callback?

I hope to have the updated eventtap up for review in the next few days, if anyone is interested in testing it out or suggesting some helper methods, once I have a better idea of what is possible.

--

A-Ron

[Chris Jones]

Hey

Silently handling the tap disable events seems like a good idea. FWIW, when I come up against odd things like that, I read both the header they live in, and do a code search on GitHub. The latter can be very informative, as you see how others are using something.

Looking forward to seeing the updated eventtap:)

Cheers,

--

Chris Jones

--
You received this message because you are subscribed to the Google Groups "Hammerspoon" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hammerspoon...@googlegroups.com.
To post to this group, send email to hamme...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hammerspoon/7e668b3e-2b83-4256-853f-e652a645b2fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Glenn Waters]

Silently handling seems good to me also. The events can be passed on in the future if necessary.

And... Yippee! I just asked about gestures a week ago and now they are happening, even if just the OS supported ones (although the taps and drags are there).

I'm looking forward to playing with the new event tap.

Cheers

______
Sent using an itsy bitsy keyboard. Expect typos and brevity.

To view this discussion on the web, visit https://groups.google.com/d/msgid/hammerspoon/B5204F79-38DF-4797-8411-A1C2666B3888%40tenshu.net.

[asmagill]

That's kind of how this idea started... I started with an idea to capture the media/special keys because I want to add a brightness dimmer to my external monitor that's tied to my laptop's brightness but couldn't decide if it should live in eventtap or hotkey, and after looking at the methods people use to capture these keys, I took a look at the header for NSEvent and realized the same code would capture at least some of the gesture events, and so that's where this ended up.  Still working out the helper methods to create, but I should have a pull ready tomorrow that at least lets us view the raw data as it comes in... how much of it should be parsed in Lua and how much handled by C -- that's where the helpers will come in...

[asmagill]

Current state of eventtap updates has been submitted via pull request, for those who want to take a look at it.

Some of the things done:

* Add additional NSEvent based events for watching

* add getRawEventData method to examine event data in more detail (really only useful to developers in determining what helper methods might be necessary, but read only, so harmless)

* Clean up types and properties documentation

* add systemKey method to get information about brightness, contrast, media, power key etc.

* add getCharacters method so eventtap can be used as a key-input capture method without having to understand every locales specific keycode arrangments

* made setKeyCode and setFlags chainable

* getProperties and setProperties know when to use integer versus number

* __tostring metamethods for properties and types tables

* auto-restart eventtaps when disabledByTimeOut or disabledByUserInput occurs

* cleaner shutdown/restart of eventtap, runloopsrc and machport

An example using the NSSystemDefined event type and watching for the brightness keys and applying a filter across external monitors when adjusting your laptops brightness can be found at https://github.com/asmagill/hammerspoon-config/blob/master/utils/_keys/brightness.lua, for those interested in taking a look.

Gesture events are defined in the event types list, but I don't know yet if enough data is captured in getRawEventData to make them useful yet... will be looking into and expanding that next week.