Ability to get mouse coordinates, when not active window

Gotta say, the control of Windows is awesome. I’m able to prototype some really cool stuff.

The Vuo window is able to get mouse positions (even outside of its window) when it’s frontmost, but not when not frontmost. Request: ability to get mouse coordinates, at all times, regardless of window level. I assume it’s not a security issue, since the screen capture node continues to work, even when the Vuo window is not active.

Opened for voting.

Thanks Team Vuo. I’m really hoping to find a way to add this functionality for a current project (which exports to a Mac app). Looking into creating a new Node Class / Library Module…but I’m not sure it’s actually possible for a 3rd party (ie me) to create a node that can access mouse data beyond what the API can provide.

Would love if I could know ‘it’ll never work’ vs ‘it’s doable’, to save me some heartbreak :slightly_smiling_face: ?

In the course of our investigation, we realized this was straightforward to implement, and required less than a few days of work.

2 Likes

Is the option #4 part of this Feature Request the same thing, at least as far as the mouse part of the FR? Sounds like it.
Came up with an idea today that I think this would solve.

“Continue receiving mouse and/or keyboard events/status even when the composition is not the active application”

Thanks. I would say ‘kind of’. Getting access to the keyboard, at all times, requires enabling that in Settings under accessibility. However, I don’t believe the mouse falls under the same constraint. Ie, any app can get the mouse position. This may have changed in 10.15.

This Feature Request doesn’t show up in the Community Feature Requests page. I ended up voting for the other version of this feature request not realizing this one was chosen already.

Continue receiving mouse and/or keyboard events/status even when the composition is not the active application  

1 Like

Thanks. Theres a distinction between mouse and keyboard on Mac OS. Access to the keyboard at all times requires the user explicitly grant the app access through Accessibility. Mouse (for now) does not. For my project, Mouse will do. Of course others will have other needs.

I don’t have any personal interest in the keyboard part of the other feature request but am very interested in the mouse functionality. I think the other request should be separated now to just be for the keyboard since this feature request now has the mouse part covered and is “chosen”.  

Looking forward to this!

In Vuo 2.3.0, we’ve implemented a new input port “App Focus” for the Receive Mouse Moves node.

This is great! Thank-you Jean Marie!

I’m really excited about this one, it enables all kinds of interesting stuff :slightly_smiling_face: