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.

Comments

Magneson (Magneson) not sure,

2bitpunk's picture
Submitted by

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

MartinusMagneson's picture
Submitted by

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. :)

Feature status

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for. Vote your favorite features to the top! (How do Vuo feature requests work?)

  • Submitted to vuo.org
  • Withdrawn by reporter