I'd like to request a change to both the LINK OUT & LINK CALL nodes:
(Add the possibility to) Display the available links in alphabetical order.
Currently, available LINK IN's are displayed in the order they are created. Having them available alphabetically would make searching for a specific LINK much easier.
Especially if you follow some type of name convention for LINKs.
Add the option to display only the currently checked conneections.
Rather than having to scroll through the list of LINKS, this option would make it much easier to see where the LINK node is currently connected to.
A Disabled LINK IN will show up identical to an Enabled LINK IN now.
It would come in very handy sometimes to see if a connection is made to a disabled link.
Hope these changes will make it to a (near) future version.
I agree with @Trying_to_learn that keeping flow groups as well is better. So if links can be sorted alphabetically per flow group that would be excellent!
Or, if I'm really pressed for ideas, maybe have a sort toggle to alternate between 3 sorting options: original -> alphabetical per flow -> all alphabetical.
Added a third request in OP.. I knew I forgot something..
The sorting thingy is slowly becoming a topic of itself, it appears..
For me, having the links sorted alphbetically within the flows is more important than having the flows itself sorted. I'd suggest starting with that and see if this presents a (better) workable solution.
Without wishing to push the scope too far, another slight annoyance I get with link nodes - especially link-in - is that, when copying a section of flow with a link-in, all of the links are also copied. It would be nice therefore to have a button/checkbox to disconnect all links at once.
Don't celebrate too early! So far, this is just a proposal.
I'll wait another day or two, to collect further feedback. Subsequently I'd create a PR ... and then it's up to the core maintainers if they accept this - or reject. And even if they accept it, it's going to last some time until you see this in a NR release.
One of the valuable latest improvements in the link-call node, was the ability to set a dynamic target (msg.target), as an alternative to selection from a list of link-in nodes. This increases the robustness, (specifically when calling a link-in node which is on another tab) as the link-in node Id may change in the other tab (e.g. via copy/paste, import etc.), and thus break the virtual wire.
My suggestion/request is to add the dynamic target functionality also to link-out nodes (today, when I set a one-way link out to another tab, I use a link-call with dynamic target, and discard the returning message).
While I understand the request, I don't get the argument of robustness. If the id of the link-in node changes, you need to "reconnect" the wire*. As such it doesn't matter if it's a static or a dynamic definition - the task is mandatory and the "workload" similar (or even slightly less in case of static wire).
Where's the benefit now to use always dynamic definition wires?
EDIT: * Or do you call the link-in by name & let NR figure out the id of the target node?
Exactly. The dynamic target serves as a "logical" node-id, resolved at runtime. Same as calling a server by hostname, not by IP or MAC address.
In our implementations, we have multiple developers working on the same system, each on his own tabs. Hence you may not be aware of changes in other tabs, and your link-outs may be broken without you knowing about it.
Moreover, a dynamic target can also serve as a "switch": instead of maintaining multiple links and routing through a switch node, you just specify a name and NR will take you to the target (you can even be forward-compatible by specifying a future target).
is there anything against making a double-click in the link-call list jump to the corresponding link-in node? I've already asked about a visual representation but that is non-trivial so instead ...
There is this treelistconfirm event that represents a double-click and could be used to place force on the corresponding link-in node. I was looking through the code and my guestimate would be somewhere here to add:
To continue on this: The elements of the list may be customized. I can imagine a link (indicating) icon, displayed on hover, that - on click - triggers a jump to the connected node in one of the flows.
Should be do-able...