It would be good to have consistency with the 'Receive Mouse...' interaction and add a 'Receive Mouse Clicks on Layer' node. Likewise the 'Receive Mouse Moves' should also have a corresponding 'Receive Mouse Moves on Layer'.
One use case might be a window which contained controls (buttons, sliders, etc) and visual I/O (input/output) layers with mouse interaction restricted to the the I/O layers.
At the moment I can't target mouse moves to a specific layer.
Other Attachments:
| Attachment | Size |
|---|---|
 XYfield with subcomp.zip | 3.54 KB |
Comments
I think you can do that by
I think you can do that by using the Ended Drag output combined with a Is Point Within Layer. See also my "InsaneMapper" composition here https://vuo.org/node/2787 for some custom UI techniques.
Magneson (Magneson) not sure,
Magneson not sure, in your comp the mapping is taking place inside a separate scaled window from the output. In my case I only have one window with a target layer for mouse interaction. I had a quick play and can see it might be a workaround but it would be more elegant to have the 'restrict to layer' option duplicated across all mouse interactions to reduce node clutter and to make things less complicated. Nice layout for the mapping comp BTW.
Not to be rude, but I'm not
Not to be rude (is saying this in itself making this seem rude?), but I'm not sure I quite understand what you want to achieve? If it is a distance thing inside a layer, it is pretty easy to get with the calculate nodes. If it's about not changing values outside a layer (XY field for instance), you can lock it with a select input and a hold node.
You can do this without the calculate node as well, but it does make it a bit more tidy. The smoothstep() function is really neat for scaling values and removes any necessity for 2D translations and such when moving around the objects/layers. Check the attached comp for the details.
The thing about UI elements/nodes is that a lot of the stuff currently in the feature requests can already be done with the existing nodes as is. Adding features/nodes will often clutter the nodes/library, and be for very specific scenarios. This means that adding a specific function will work for a user wanting X, but not for a user wanting X.b without adding yet another port/function to an existing node - or building the function with other nodes. In the case of the latter solution, X could have been achieved from the start by using a sub-composition tailored to that users wishes and then be shared and modified by user B. Then team Vuo could focus on stability improvements for existing nodes, and adding more spicy base features for the things that are hard to do instead. :)
XY_field.png
XYfield.vuo
Magneson hey, not rude we are
Magneson hey, not rude we are coming from different directions. I had thought about locking the movement to the layer bounds but hadn't managed to get it to work yet. Your example comp is exactly what I was thinking. Thanks for taking the time to share the method, cheers.
Here's Magneson's solution as
Here's Magneson's solution as a
Receive Mouse Moves on Layersubcomposition for easy reuse. You could make a similar subcomposition forReceive Mouse Clicks on Layer.Since that seems to solve the problem, I'll mark this feature request "Withdrawn".
XYfield with subcomp.zip