Inputs auto links

Created by: portnov

Addressed problem description

Good node tree usually has most of it's "vital" parameters defined in "input" nodes, such as "A Number", "Vector In" and so on. It's better to have separate nodes for meaningful node parameters, because you can explicitly name them ("Building Height" instead of "Z"). But linking all inputs of all nodes to separate input nodes and naming those nodes is tiresome process.

Another thing is that I usually tend to group input nodes in specific places of my node trees; those places can be far from places where parameters are used, so there are very long noodles. WiFi nodes can make node trees cleaner, but manually creating and linking them is tiresome too.

Solution description

For input sockets, that have good "input" node counterparts ("A Number" for Strings socket, "Vector In" for Vertices socket), add a dropdown menu, that allows:

• create new input node and link it to this socket; the node will be automatically named with the name of the socket.
• create new input node and link it to this socket, but instead of direct link, create a pair of WiFi nodes and link input node via them;
• link this input to one of existing parameter nodes of corresponding type;
• link this input to existing WiFi In node.

The menu button is shown only for sockets that have associated node property. But maybe it worth to replace all existing "quicklink" buttons with this new menu?

Also I think I'll show these new buttons only when "Show socket menus" checkbox in the N panel of the tree is checked.

I know that @Durman has reservations about WiFi nodes being too implicit, and I partially understand his concerns. But also I think that WiFi nodes can be very useful when used wisely. So I wait for input from @vicdoval, @zeffii , @nortikin : is it good idea to simplify creation of WiFi node pairs? Will we continue to support them?

Preflight checklist

Put an x letter in each brackets when you're done this item:

• Code changes complete.
• Code documentation complete.
• Documentation for users complete (or not required, if user never sees these changes).
• Manual testing done.
• Unit-tests implemented.
• Ready for merge.