Combined Keyboard and Mouse Trigger
It would be nice to use a combination of keypresses and mouse clicks as a trigger.
This would allow triggering fast additional editing commands.
Is there a workaround at the moment with a runForever Script waiting for the occurrence of certain modifiers in combination with a mouse click?
Christian Scheuer @chrscheuer2020-11-11 17:09:48.484ZThis would be great to have indeed!
The biggest hurdle for this is that the macOS API's we use to hook into the system don't allow us to capture mouse events in the same way we do key presses. To have this really work, we'd need a kext (kernel extension), and so far we'd tried not to do that, since the added complexity and cost of building (and especially, keeping up to date with the constant changes Apple makes) such an extension would far outweigh the advantages.
- JJascha Viehl @Jascha_Viehl
"don't allow us to capture mouse events in the same way we do key presses. " means also the workaround with a runForever script isn't possible?
Another, although clumsy, workaround would be to have a keyboard trigger for a Surface which shows up with a confirmation button right under the mouse position so the next click would fire a command and close the surface.
Right now I think there is no support for defining the position of appearance for a surface, which would be nice for many cases.
This would allow for a new contextural mouse menu for even more than one trigger.
On button click, the surface should close again. This will be possible soon, right?I made a screen recording to demonstrate the workaround:
Mouse Click Workaround.mov (0.99 MiB)
Christian Scheuer @chrscheuer2020-11-11 18:20:55.568ZHi Jascha,
Unfortunately, macOS doesn't allow us to capture the mouse event, meaning the mouse event will be passed on to the app under the cursor, no matter what we do.
You're right, that if we were extremely lucky and the positioning of a surface could be made quickly enough so that the mouse click would be intercepted before being passed down, there's an off chance that it would be possible to use that to capture the mouse click so it doesn't propagate to the app that was actually present at that position.
However, due to the nature of the different threads being in play here, I don't think it would be a stable solution. It would essentially be a race for the threads and the Window Server to compete for "who gets there first". I'm not sure we would always get there first. It also would be extremely fragile in that it would bypass official macOS guidelines, so you'd be risking it stopped working on even a patch upgrade of macOS, if for example they changed the heuristics, performance or timing of internal macOS components.So I wouldn't (officially) recommend going down that route. You may get it to work sometimes, or most of the time, but there's also a high probability of it often not working or being unstable in different ways.
Note: I'd love to be proven wrong, but that's my analysis of the issue.Right now I think there is no support for defining the position of appearance for a surface, which would be nice for many cases.
This is on the roadmap :)
This would allow for a new contextural mouse menu
If I understand what you mean, then this still talks about capturing mouse clicks, which we cannot do. We can react to them, but we cannot keep them from bubbling.
- Christian Scheuer @chrscheuer2020-11-11 18:25:15.251Z
Forgot to reply to this:
Is there a workaround at the moment with a runForever Script waiting for the occurrence of certain modifiers in combination with a mouse click?
No, not at this moment. SoundFlow only supports the 3rd mouse button and scroll events (both in combination with potential modifiers), since we can capture those.
I don't expect we'll be able to add this functionality anytime soon, if at all, given the restrictions by Apple's APIs as mentioned above. - In reply tochrscheuer⬆:JJascha Viehl @Jascha_Viehl
If I understand what you mean, then this still talks about capturing mouse clicks, which we cannot do. We can react to them, but we cannot keep them from bubbling.
I meant a keyboard or Stream Deck or otherwise (not mouse) triggered surface appearing at the mouse position.
Like a custom right-click menu but triggered via keyboard.This could be:
- a quicker fade dialog with only three options.
- selection of specific field recorder channel numbers for multiple clips.
This would be very versatile and faster than to lay out multiple options on a Stream Deck for example.
I'm waiting for the mouse related positioning of surfaces and hiding a surface via a command then.- Christian Scheuer @chrscheuer2020-11-11 20:22:05.357Z
Gotcha! Yes, that would work, I think.
- BIn reply toJascha_Viehl⬆:Ben Rauscher @Ben_Rauscher
Curious what the latest information is on this subject. One of the main benefits to using Keyboard Maestro over SoundFlow is the ability to utilize modifiers with USB key triggers (ie: CTRL + CMD + Kensington Trackball Button 4). KM is just $36 (or four months of SF) and he's had it working just fine for many years.
- Christian Scheuer @chrscheuer2024-08-19 10:32:17.561Z2024-08-19 10:39:08.052Z
Hi Ben,
I don't own a Kensington Trackball so I've never been able to test more deeply with this. At the moment, there are no updates to this specific functionality.
Note that it's perfectly possible to use KM and SF together, if there are trigger types supported in KM that SF doesn't (yet) have.
Quick note to your complaint that this has not been implemented yet. The quick reply is that this is not a highly requested feature. As you can tell, there's been almost no interaction on this idea/thread for ~4 years - until your comment a few days ago, just a single user had voted for this idea. We have to prioritize feature requests based on what the community is asking for.
The best way to vote for something you'd like us to work on is to add a like to the thread (Jascha's original post).