There have been many times when I wished I could have had two (or more) node editor windows open at the same time. My current solution is to screencap one of them and set an image viewer to always-on-top, but of course this doesn't allow you to copy/paste text from one to another.
It would be great if we could 'pin' a node editor window for situations like this.
Perhaps a little visual feedback/colour-coding/alternate styling would help to identify which editor was which when two of the same type of node were open at the same time.
I think @daxliniere is referring to the node edit dialogs, rather than the full browser window.
Unfortunately, that isn't possible given the way the dialogs work. It would be a breaking change and require all nodes to change how their provide their edit dialog content. With over 3500 nodes in the community, that wouldn't happen.
Even making it a breaking change across a major release would take a long time for the community to catch up so you'd have a suboptimal experience.
Of course. "tear-off" panels would be a fantastic addition to Node-RED. But of course, we are limited to what browsers can do. The Editor page will be assuming that everything is part of the page and so communications between elements is simplified. Once you move some elements to a new page by "tearing" it off, you open up a whole bunch of annoying new communications problems that you have to deal with.
It is certainly possible - Nick did it with the Debug Panel which can be separated. But it probably isn't easy and would likely be a lot harder for the node's settings panels.
As always, it doubtless comes down to priorities - is this more important than other developments on the backlog? And to resources - who would do the coding and testing?
I would certainly back this as a future enhancement for Node-RED but given there is a work-around, my personal opinion is that this wouldn't be very high up the priority list. Thankfully, it isn't up to me though.
I doubt this is a browser limitation, especially since Nick suggested it would require some refactoring of the back end. Browsers can happily render as many 'panels' as you like and as I see it, each panel could simply be sending new settings to a specific node (as it would need to be doing right now).
I don't believe that is how the Editor currently works. The code for a node's panel is loaded into the editor and therefore inherits a bunch of information and communications from it. To disaggregate the panel from the Editor would likely be a lot of work. It would certainly need someone to go through and find out what parts of the Editor are needed to support the panel. There are a growing number of events as well so they would also need passing through to a disaggregated panel. Some of those events pass the node objects belonging to other nodes and that might not be particularly feasible if disaggregated. uibuilder for example makes use of some of those events to track undeployed instances of uibuilder nodes because the URL setting of each uibuilder instance has to be unique.
That's what my first response was. You just open a new Editor window
But the request was for the node's settings panel to be made available as a separate window and that is different.
Yes, you can certainly clone the Editor but if you want just the panel, that leaves other things that have to be dealt with such as window sizing.
All things are possible as I also said. But is it worth it? Well that's for others to decide. Personally, I think there are more important things to focus on.
As I explained in my first reply, it is not possible to have two dialogs open at the same time within the editor. It's a far deeper issue than just having to resize things...
The content for a nodes edit dialog is provided by the node itself. That content will have hardcoded IDs for all of the elements in the dialog - such as node-input-name. It might also have custom event handlers that get attached to elements by their id.
If you open a second dialog, then it will add elements to the page with ids that already exist. Which is invalid html. The browser no longer knows which element is which. None of the second dialogs event handling will work because it will get attached to the elements in the first dialog.
The fix is to scope the element IDs to be unique. However, as the content for the dialog is provided by the nodes, this is not something we can fix in the core. It would require all 3500+ node modules to be updated.
It certainly is possible to have the info sidebar open at the same time as the editor. So if the need is to copy/paste one node config to another, that is one way of doing it.
You do end up with the raw view of the properties, so for more complex configs, it might not be as obvious which property maps to what bit of node edit UI.
But having copy shortcuts to the node info properties table would definitely be helpful - we should do that.
So that it copies the value in the correct format - ready for pasting into the edit tab?
NOTE: that GIF demo was only possible due to a quick hack using RED.events.emit to cause the properties table to update on click of an item in the info list (currently, a single click of a tree item in the info-tab does not update the properties table).
for the memory banks...
in treelist.js, line 727, added RED.events.emit("view:treelist-selection-changed",{nodes:[RED.nodes.node(item.id)]}); inside label.on("click" callback
in tab-info.js, line 580, added RED.events.on("view:treelist-selection-changed",refreshSelection);
Sorry, it wasn't clear what the gif was demoing that isn't possible today. I can't remember off the top of my head every behaviour and interaction
So without getting ahead of ourselves, and without taking this thread too off topic, we should understand what interaction is desirable and what is needed to get there.
Nothing more than turning on the 'copy value' button as we have in the debug sidebar. We're reusing the same utility to build the Dom element that displays the value - turning in the copy tools "just" needs the right options to be passed in (iirc).
I thought that might be the case Nick so added the below...
Stop being modest
Yes - i think it would take a good deal of time and effort to understand if updating the table would have adverse effects and as you say, would it satisfy the request?
sounds good. and simple. and useful. How should we capture this suggestion Nick?
Absolutely, yes.
As someone who is still learning Node-RED (and, indeed, programming), it's really beneficial for me to be able to compare/copy/paste between the editors of two nodes, and I dare say many others are in the same boat.
Steve's solution, though not 100% visually perfect, seems like an excellent solution, given the limitations that exist. Adding a copy button would certainly be a long way to my suggested enhancement.
What about a middle-man? (see below)
I'll be the first to admit I know SFA about programming and how the internals of NR work, but is it not possible to add a 'layer' between the node and the editor which can append an identifier (something like '.editor#1') to the input coming from the editor but passes that to the designated node without the editor instance identifer suffix?
If it was as simple as that we would have done it a long time ago. I have tried to explain multiple times there is not a simple fix we can do in the core that would magically change the behaviour of 3500+ modules that have been written.
To repeat myself again: each node provides its own logic about how it accesses the input elements it adds to the edit dialog. If the editor changes the ids of elements a node generates and expects to use, we would also have to dynamically re-write all of the code and logic the node provides to know about those ids. That is simply not feasible.
Please understand - I am entirely sympathetic to the user requirement. But it is not technically feasible to achieve.
Of course. "tear-off" panels would be a fantastic addition to Node-RED. But of course, we are limited to what browsers can do. The Editor page will be assuming that everything is part of the page and so communications between elements is simplified. Once you move some elements to a new page by "tearing" it off, you open up a whole bunch of annoying new communications problems that you have to deal with.
