[LINK OUT & LINK CALL] Usability Requests

Core Development Feature Requests
1

I'd like to request a change to both the LINK OUT & LINK CALL nodes:

  1. (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.

  2. 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.

  3. 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.

Thanks!
DenW

4 Likes
2

That looks like a 1-liner - which makes a lot of sense (for me).

How about a checkbox above or below the list of nodes, labeled "Filter for linked nodes" or "Show linked nodes only"? Implementation isn't that difficult either...

Any objections / alternative opinions?

1 Like
3

I've asked for this too.

When you have a lot of these kind of links and want to check who is connected to whom it is not easy with ALL the nodes shown.

The option to show only connected nodes would really be handy.

WRT sorting.
Maybe good.
But I think keeping the flow groups is better as if you are only looking for links on this tab having them ALL sorted could be painful.

2 Likes
4

No objections here.. :slight_smile:

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.

Sorry I can't do the work myself..
Thanks! DenW

1 Like
5

I guess that fell through the cracks about HOW they are sorted alphabetically.

On that maybe sort the GROUP names rather than having the order they are in the tab list.
That is a grey area too - alas.

Sometimes I have all my MAIN flows - say - at the left and the play flows at the right. (New tabs etc)
and so if I am searching for links near by having them in tab order would be better.

But if you get down to the basics of names, then the tabs/groups should also be sorted.

(Another option in the sort type list?) :wink:

Just saying.

6

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.

7

Preview:

LinkNodeTest

  • Flows are displayed in the order as they appear in the editor.
  • Link In nodes are ordered alphabetically. Was thinking about sorting those with the default label Link In ### according to their trailing number. Opinions about this?
  • Selection of connected link nodes by checkbox under the list.

Is there a standard style to depict labels of disabled nodes? As you might have noticed, I applied greyish color and a dashed underline. Better ideas?

2 Likes
8

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.

9

That looks very usable to me!
Great that you could do this on such short notice.

To my knowledge, there is no standard style for disabled nodes.
The way you've done it here seems perfectly fine! :slight_smile:

Thanks for your work on this, much appreciated.
DenW

10

Don't celebrate too early! :wink: 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.

11

While we are at it... let me add another request.

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

12

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?

13

Update to the sort order:

  • Sort is always done lowerCase().
  • link in and link out nodes with a default label will be be ordered according to their trailing number:

image
image940Ă—464 18.9 KB

14

That is kinda how link call works. From memory,:

  • if there is single link-in matching the name in target found on any tab, it calls that.
  • if there are multiple matching named link-in but only one of them is in the same tab, it calls that.
  • Anything else, an error is thrown.

It was designed this way to permit copy and paste across tabs without having to rename links.

2 Likes
15

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

16

Hi There,

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:

.on('treelistconfirm', function(event, item) {
     if ( item.node ) {
          RED.workspaces.show(item.node.z,false,false,true);
          let ndeid = item.node.id;
          setTimeout( () => {
            RED.view.reveal(ndeid, true);
            RED.view.redraw();
          }, 38);
     }
})

then double clicking on the entry would move to the link-in but only for the link-call node.

1 Like
17

Seems like a cool idea to me and a potentially nice small enhancement.

1 Like
18

I tried this out and it doesn't work because the list-item has a radio field which means that the treelistconfirm event isn't triggered (see here and here in the treeList code).

Secondly using the double-click is actually bad design idea since it implies changing the target of the link-call node, i.e., when dblclicking a link-in target in the list causes it to be selected.

Oh well, it was nice while it was an idea!

19

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

1 Like
20

Should be do-able...

Can I ask it is not done as part of any initial PR to improve the sorting etc of the list? I have UX concerns over this bit and I wouldn't want to hold up progress on the other aspects.