That ^^^ should work...
1 Like
So nicely it worked!!! Just seven minutes on a RPi4 with a lot of stuff in the flows
Besides, the new feature for Link calls, how good is that!!!, Thanks, Steve!!
Link Call: Display link targets of nodes in a regular flow, for Link Call nodes inside a subflow (#3528) @Steve-Mcl
3 Likes
Sorry guys, I missed this one (my bad 
)...
1 Like
Like @krambriw , I've just up upgraded one of my RPi-4B to NR 3.0.0-beta.1
Worked fine and took just over 4-mins.
I used the command line command as given by @Steve-Mcl above.
2 Likes
Great news, nice new features.
Any breaking news around Projects ?
I started to use that feature recently and I love it and they are a few things that I would believe make this great feature into an awesome one:
- It would make a lot of sense to integrate an equivalent of "node-red-contrib-flow-manager" inside Projects. Having the ability to stage/commit per flows & subflows makes a lot of sense for development management: ability to revert commits, merge commits across branches, ....
- Automatic install of dependencies (unless I've missed a way of doing it)
Happy to open a topic about it if you'd like
Thanks for the great work
1 Like
@Steve-Mcl If you are taking requests 
If I click and drag I can select two nodes and move or delete them together.
If I ctrl-click on two nodes they are both selected and I can move or delete them together.
If I click and drag I can select two junctions and move or delete them together.
If I ctrl-click on two junctions it draws a wire between them.
Doesn't seem very consistent?
A Junction acts as both a Node and a Port - so they have a take a bit of behaviour from both things.
Click-Drag on a node moves it
Click-Drag on a port starts a wire
It felt right that Click-Drag on a junction should move it - (node-behaviour)
But it is also reasonable to expect to be able to create a wire from a Junction - so the question is what interaction makes sense to do that. Given Ctrl-Click-Drag on a port starts a wire, that felt to be the option to chose rather than invent yet another combination for users to learn.
If you have a suggestion for how else that could be achieved, we'd welcome the feedback
Yes, thinking about that...
Another issue with junctions:
You can draw a wire from a junction to a node, deploy and data flows along the wire (top of pic).
But if you draw a wire from the node to the junction and deploy, data does not flow down the wire (bottom of pic).
This is a known situation...
EDIT
Looking at this again, this might be slightly different to the linked issue 
@knolleary ?
- Create a 1 to many flow
- Wire backwards from input to junction
- deploy - no msg (as expected)
- Export and Import (duplicate 1) OR copy & paste (duplicate 2) loses the wire
@jbudd thanks for the feedback
Edit 2 @jbudd sorry, i didn't notice your follow up post. I see the same issue.
Thanks Steve. It may well be caused by the same code "feature" but my example does not involve wiring junction to junction, nor deleting a previous wire.
After a bit more poking I'd restate it like this:
If you wire a node input port to a junction, the line is visible in the editor but not added to the junction's "wires" array.
Then if you deploy and reload the page, it (obviously) is not drawn.
Going back to click-drag action on a junction:
As you say, click-drag on a port starts a wire.
A junction looks similar to a port so I would expect click-drag to act the same.
But since it does not, you get situations like this:
You can highlight a wire and shift-click-drag to move it from a port to a junction.
But highlight it again and shift-click-drag moves linked nodes on one side or the other rather than moving the wire.
The only solution I can think of is to draw the junction similar to a do-nothing function with a body and ports.
I'm sure the design conscious developers will veto this though.
Indeed. If that was the approach we took, we wouldn't have bothered with the feature at all because thats what you already have with noop nodes.
The goal here is to have a more discrete way to route the wires without the visual clutter of a whole node.
1 Like
It's a new concept and I'm sure it'll go thru a few iterations before it all works out
We've all wanted this for so long that I, for one, am well prepared to spend some time working out what a good UI for it is 
6 Likes
I felt guilty & spared some play time to fit this in...
Not guaranteed to be in final v3 since beta is out but its there waiting in the wings.
1 Like
Either way, it's a big step forward.
Thanks, Steve
OK - updated my working instance on a Pi4 - lets see what I can do with the new junction nodes instead of present way with null function nodes
[Edit] Modified flow (took one existing function node out all together but otherwise identical)
As discussed by others, only being able to add wires to the junction not from it, is a restriction (which I can live with)
Not being able to use shift modifier to move a wire from a junction was more of a restriction I felt
My suggestion would be to make the junction actually two nodes (in and out) next/close to each other
But we'd need an alternate beta being produced to try it out
As usual, had to stop my broswer (Vivaldi) from interpreting the shift-right-click_and-drag and let NR have it
What would be VERY nice would be a method of doing a global search and replace on dummy function/change nodes with junction nodes
Maybe possible with text editor (or a running a little script) on flows.json???
Keep in mind this forum post is about the beta - it doesn't replace posting to #development:feature-requests with ideas that could be considered for the future.
Well, having a native way of putting a junction-type node into place is an enhancement in it own right (not having to edit the function node to change it to an icon)
A closely coupled junction node would be less visually cluttering (and allow for finer wire routing) than the current icon sized method.
But as you say, a single junction node would be less cluttering again.
If the editing restrictions on a single junction prove to be insurmountable, then maybe a closely-coupled pair will be needed
