I'm working with node red for more than one year within home assistant (~1.100 nodes in several flows over 9 different flow-dashboards). And therefor here comes my question to, as a node-red-develloper: Is it possible to shrink the topic-line of each flow-dashboard individually (like columns in an EXCEL-sheet)? This feature would make it easier to jump from one sheet to an other without scrolling. Thank you in advance for any response.
By "Dashboard", I clarified they mean the Node-RED Editor, and want to be able to resize the tabs in the Node-RED Editor so that they can access the many flows they have, rather than needing to scroll.
This is one of those "you cannot satisfy everyone" type of things - where you see different browsers take different approaches. Chrome takes the 'lets cram everything in' approach, where the tabs get so small you can't actually tell which is which anymore.
Our current behaviour is more inspired by Firefox - shrinking tabs to a minimum before scrolling. Of course, the choice of what that minimum should be is quite subjective. Unlike browser tabs, we don't have a favicon to help distinguish tabs.
This was also one of the motivations of adding the info sidebar list of tabs, as well as the ability to Ctrl-F to 'find' a tab and switch to it quickly.
If anyone has any suggestions for improvements, please do share.
It does take a long press to get from the left hand tab which the browser opens at, to the right hand tab which I most recently created and am still working on.
I recently created myself a treeList with recent tabs, a kind of stack with the tabs I've visited. The most recent visited tab is always on top.
A typical workflow for me is copy some text, find a node where the text should go, switch tabs via the find dialog, make the necessary change and then want to go back to the original node. No idea where it was or what it was... that's were I loose track of my tabs. Hence I built myself the tab stack treelist tracker.
Eventually all my tabs will be in the list and become a duplication of the info sidebar tab but the most recent tabs are always on top, that being the difference.
My 2cents are that the tabs should maintain a minimum width with scroller, i.e., as is!
I like the way Edge does it, with the option to have a collapsible vertical tab list at the side.
You get lots of tabs visible at the same time and scrolling is fast using the roller wheel, and the whole thing can be hidden with a single click to give max width.
So if we are going to open up this subject, a couple of thoughts from me.
A quick "win" might be to make use of either a setting in settings.js or even just an easily adjustable CSS variable so that people could set their own min/max tab settings.
Draggable individual tab widths might be nice but probably a lot of work for minimal gain. You'd need to think about retention of settings of course and to ensure that settings for tabs get removed properly with the tab.
The one advanced feature that I would dearly love though for the Editor would be NESTED TABS. Even just 1 level of nesting would be tremendous. Most, if not all of the Chromium-based browsers now have "tab stacks" where you can group a set of tabs together.
Tab groups should have their own name setting, the ability to set a group colour would also be nice.
Perhaps a different take would be to consider having too many tabs as a code smell? Since each tab represents a bunch of nodes connected together in a flow, this implies more code, so many tabs mean a lot of code - perhaps too much code? Harder to keep an overview ...
Perhaps too many tabs are indication of having to refactor the code base? Or perhaps if you can deal with many tabs then all is well for you.
Taking this point of view, the tab layout should perhaps be optimised to make this smell even smeller, i.e. to encourage a certain amount of reflection upon the codebase.
It's important to remember that tabs in Node-RED are not the same as tabs in a browser - tabs in a browser are not interconnected or depended on one another while tabs in Node-RED are very much interconnected and depended on each other.
Running on the same instance of Node-RED ... so a long running flow in one tab has influence on other flows - but on the server side.
EDIT: ok one could argue the same thing about browser tabs but they are actually sandboxed (and I can remember the amazement when Chrome was the first browser to have this feature) and are designed not to influence each other, i.e., in performance.
I try to organise mine so there is very little direct interaction, each tab containing the logic for some aspect of the system, using MQTT to logically isolate the tabs. So there is a tab for the kitchen temperature control, one for hot water heating control, one for the 3D printer control and so on. For the UI I generally have one tab for each ui page, but all the data comes and goes via MQTT so there are no direct links to other tabs.
This leads to a large number of flow tabs each containing a fairly small amount of logic, which makes it easier to maintain, but there are a lot of tabs.
don't get me wrong, I have the same problem but I'm just suggesting that the same metaphors that hold when dealing with browser tabs might not hold for NR tabs.
I've moved away from using the tabs directly - because of the sheer number of them - and instead using the find functionality and the tab stack feature that I now have.
I guess I'll be really happy if we could code our flows in 3D and then have all our flows stacked nicely next to each other (thats is a 15MB gif of my mind map - might not work).
I don't use it. Because if I click on a flow it opens the listing of the nodes instead of opening the flow in the editor - for that you have to learn to click on the magnifying glass.
Also I don't use the "search flow" dialog - the find is so much simpler: Cmd-f "flow name" compared to click on 'i' tab, click into search field and then type.
I suspect that the info tab was invented before the find functionality.
I use the lower half of the info sidebar a lot because I have a lot of texts that I preview in that window. But that's another story.
It is possible that there is no one solution fits for all. How about keep current tabs but add possibility to open and pin tree view to left side of screen? Also add flow groups what allow organize fows to that treeview. I dont like much to put that tree to right side behid buttons because it will slow down use when I do modifications to multiple flows.
I inderstand that my usecase is quite extreme with almost 50 flows. Another hand if I can manage and arrange flows I would probably have 100-200 smaller flow instead of current 2-8x 4k canvas mammoth flows.
