I would like to see the ability to optionally dock the 'Node Edit' property panel so that it is remains open and updates as different nodes are selected. It doesn't need to support editing properties of multiple nodes at once
The reason is that while developing and debugging a flow, I often find myself inspecting the properties of many nodes and perhaps tweaking some of them. Double clicking to open the editor is fine, but to switch to another node means clicking off the panel, waiting for the panel to retract and dbl-clicking the next node. Of course this is not a hardship but I am used to IDEs that allow for docking of panels and it makes for a much smoother, quicker flow.
Even if docking cannot be supported, the next best thing would be to allow configuring the panel animation duration so that it is immediately shown/hidden - this would help. Perhaps I can even look at adding that myself?!
Thanks.
PS, I love Node-RED, and I'm constantly impressed by the next thing I find that I can do! Definitely one of the best development applications I've used. Thanks to all the contributors!
We have so far resisted the idea of surrounding the main workspace with hundreds of extra windows (like many ides we could mention) and that is a deliberate choice. Of course we always like good well reasoned feedback so never say never.
Perhaps if this "properties" window was a tab on the sidebar? - meaning there is no extra window cluttering the workspace?
I've worked with many IDEs over the years and this is a common pattern.
Of course I understand if it is in more effort vs benefit it might not be feasible, but if you found, with all the tooling and components already developed it turned out to be a relatively easy and quick thing to implement, I'd welcome this feature.
Again,
Edit...
I do believe this would take (already high) productivity a notch further.
Don't forget you can already "show more" in the info panel which shows the actual properties all the time
gives
from there you can click another node and see it's internal properties etc. As they are just a list of the internal properties they not be as nice as the edit panel - but for an advanced developer I'm sure you would get the gist pretty quick
Tbh, I know this is present but i can't quite put my finger on why I don't use it. I suppose due to being different to the familiar layout of the editor for the common nodes, I can't instantly see the property I'm interested in. (And obviously, the properties in this view cannot be edited)
@dceejay from your knowledge of the components that make up the UI, off the top of your head, forgetting for a second how events and linking would be done, would hosting the editor dialog in a tab on the side bar be a major undertaking/rewrite or are the components written in a manner that would permit relatively easy placement in another view?
Either way, I am very appreciative of the work you guys do and very happy with everything regardless.
Yes. I've looked at it before and it is not a simple change. The lifecycle of the edit dialog doesn't fit this model.
When the dialog is opened, the node's oneditprepare function is called to build the form. That could involve expensive actions such as background http requests to load additional information.
When the dialog is confirmed, oneditsave is called which could, again involve background http requests and other expensive actions.
That model does not fit well with the dialog being always displayed and changing each time a node is selected.
There is nowhere the user can confirm or cancel their changes.
Another benefit with the current model is the info sidebar is visible at the same time as the edit dialog - which means the node's help text is visible at the same time. Putting the edit dialog into the sidebar would hide the node help at the precise time a user may need to refer to it.
None of these problems are insurmountable, but nor are they trivial.
Just on the benefit of having editor and debug visible at same time, I do agree that is something I often do to see where values / variables are. That would be a miss (or a chore switching).
Perhaps the editor could still be "popped out" or maybe in a vertical split view above or below the debug pane?
Anyhow, thanks for responding. Good to know it's a consideration.
I would not call it an active consideration. It has been considered in the past and ruled out for the various technical reasons I described. There are no plans to revisit it.
I agree it shouldn't be a permanent fixture or even in the sidebar, which is why the request is to have an option to dock it where it currently is.
@dceejay Ref the info panel, yes it is sometimes useful but you have to understand the internal IDs and nomenclature. Also, some rules/behaviours are tucked away inside objects or even nested objects which have to be expanded manually each time the info pane is refreshed.
@knolleary There are patterns for saving/cancelling changes in docked editors and I don't think there would be a change in behaviour to what there is now. For example, if I click away from the editor, my changes are saved without even clicking 'Done'. If I want to cancel, I still have the option of clicking cancel.
Regarding the potential issue with a node doing something 'time consuming' before the editor can fully load - that would be a problem today, so perhaps it is rare enough to not worry too much about? Now, if the editor loaded asynchronously and told you it was doing something and could be pre-empted by clicking on the next node, that would solve it, but the can of worms is getting bigger
FWIW, I edited the style.min.css & red.min.js to set the editor transition duration to 0 seconds and reduced the delay in hiding the 'grey shade' over the main window (I know I will lose the edits on update). This means the editor displays instantly and I don't have to wait for the 'disabled' node view to become enabled again in order to dbl-click the next node. It's now got some pep, but docking would be so much nicer...
But the point is, you are now asking the editor to be constantly doing that time consuming work whilst you are clicking around the nodes regardless of whether you want to actually edit the node or not. When I last played with this sort of concept (a couple years ago admittedly) the constant flickering of the dialog while clicking around nodes didn't look good.
The 100ms delay whilst the editor panel slides out hides a lot of sins for some nodes.
There is also the screen real estate question. If you have the sidebar open and the editor dialog open, you aren't left with much room for the flows.
I'm sure there will be some tweaks to improve matters, but I'm still in favour of the user taking a more assertive action to show the edit dialog.
Yes, I am asking the editor to do more work, but until it becomes an issue, why not? I am used to highly configurable IDEs where where you set it to what makes you most productive. I have a super wide monitor so real estate is fine, you can always zoom out the flows and flickering I can live with if it makes me more productive. When I am finished in the 'dock' mode, I turn it off and the window disappears again.
I know this is purely an optimisation and I am impatient when I have to wait for animations, which is why I have disabled them on Windows and on my iPhone. Most people probably don't mind which might be why you haven't had this suggestion before
Disabling the animation and timeouts has improved matters for me.
Anyway, I understand that it is not a simple undertaking and there are tons of more important things to work on! Thanks for entertaining the suggestion and responding, appreciate it.
