fertshelf.blogg.se

1. #HAMMERSPOON OPEN APPLICATION DOCK KEYBOARD SERIAL#
2. #HAMMERSPOON OPEN APPLICATION DOCK KEYBOARD CODE#
3. #HAMMERSPOON OPEN APPLICATION DOCK KEYBOARD WINDOWS#

More detail as to why I'm asking, if you're curious - you don't need to read this, but I would appreciate an answer to the above, if it's not too much trouble.Īs we see more complex examples that people come up with, we've found that some combined actions are timing dependent, and we can insert delays at specific points to make them more reliable, while others require the main thread of Hammerspoon to be idle, if only for a few nanoseconds-to-microseconds, in between actions. (The doAfter won't happen before 0.001 seconds, but may actually happen later because it requires the Hammerspoon application event loop to advance so that the timer can trigger the callback function) I ask because this will tell us whether it's an issue of giving the app time to activate, or whether its an issue of requiring the Hammerspoon application event loop to advance. SLPSPostEventRecordTo(window_psn, bytes2) Īctual change in a question: does app:activate() hs.leep(10000) win:focus() (you can try any number between 100 to fine tune it, I just chose 10000 because if that doesn't work, then 1000 won't either) work?

SLPSPostEventRecordTo(window_psn, bytes1) Memcpy(bytes2 + 0x3c, &window_id, sizeof(uint32_t)) Memcpy(bytes1 + 0x3c, &window_id, sizeof(uint32_t)) but it doesn't actually get treated as a mouse-click normally would. basically synthesizing a mouse-down and up event targetted at a specific window of the application, the information specified in the events below consists of the "special" category, event type, and modifiers, Static void window_manager_make_key_window(ProcessSerialNumber *window_psn, uint32_t window_id) It has been quite some time since I implemented this, so I don't remember all the nitty gritty details of all the events, but the solution for this particular issue boils down to combining the following steps:įirst just some definitions that are necessaryĮxtern CGError _SLPSSetFrontProcessWithOptions(ProcessSerialNumber *psn, uint32_t wid, uint32_t mode) Įxtern CGError SLPSPostEventRecordTo(ProcessSerialNumber *psn, uint8_t *bytes) There were multiple such system events being triggered in this scenario. The background information that helped me discover this was that I was trying to implement focus follows mouse (autofocus) by looking at how macOS was able to focus a window without raising it when clicking inside the window belonging to an unfocused application while holding the ctrl + alt modifiers.

#HAMMERSPOON OPEN APPLICATION DOCK KEYBOARD SERIAL#

Anyway, we can then synthesize such an event and send it directly to the target process using its process serial number. I'm not exactly sure what this event category is, but I'd refer to them as either system or control events. B1 and B2 are on top, C2 is currently focused.īasically what I discovered is that there is a certain category of events that are passed by the system to applications depending on how it gains focus.

#HAMMERSPOON OPEN APPLICATION DOCK KEYBOARD CODE#

RESULT: The code above popups up A2 but it is not focused.B1 and B2 are on top, B1 is currently focused.Expected outcome in both cases to open and focus A2.

I also have some other app C2 open on screen 2.

#HAMMERSPOON OPEN APPLICATION DOCK KEYBOARD WINDOWS#

Let's say I have two chrome windows (A and B) on each screen (1 and 2): A1 and B1 on one screen and A2 and B2 on another. Local app = hs.appfinder.appFromName(appName)