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.
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://community.vuo.org/t/-/6621 for some custom UI techniques.
@MartinusMagneson 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 (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. :)
XYfield.vuo (9.95 KB)
@MartinusMagneson 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 @MartinusMagneson’s solution as a Receive Mouse Moves on Layer subcomposition for easy reuse. You could make a similar subcomposition for Receive Mouse Clicks on Layer.
Since that seems to solve the problem, I’ll mark this feature request “Withdrawn”.
XYfield with subcomp.zip (3.54 KB)
Hi @jstrecker,
Thanks for creating the subcomposition I will have a play :-)
Re-closing the feature request I would suggest its still relevant particularly for new users. The subcomposition solution will get buried in the forum over time and we should really be striving for consistency with the top level nodes. Maybe this is a conversation about rationalising functions across node groups. Inconsistencies will only confuse new users.
Edit:
Also you have now labelled the feature request “Withdrawn by reporter” which is not the case, I have not withdrawn the request.
Others may feel the report has merit based on the obvious inconsistencies with the node groups features. I would assume any feature request which highlights inconsistencies in a group of nodes should be discussed and not just circumvented using a subcomposition.
Oh sorry, I misunderstood. Opening this feature request for voting.
