This is a UI question related to tabs. This is more a conceptual question related to what tabs represent.
What I've noticed that if I have many tabs (i.e. flows) are open and I want to switch between two tabs on a wide screen, then going from the far-left tab to the far-right tab is a long journey for my mouse. I could just move the tabs to be next to each other and then I've solved that problem. But ...
I was having a conversation about this and I thought about my Emacs and it's handling of buffers. In Emacs each buffer represents an open file and I could have - potentially - thousands of buffers. Each just being a link to an open file.
I have always use two emacs windows, each with two frames. So that I have - visually - always four buffers "open", since each frame contains the content of exactly one buffer and each window can have many frames (or just two as I do).
For each frame, I can select the buffer that should be displayed. So that when I follow the flow of my code, I would regularly swap out buffers that are shown in frames.
Conceptually this is opposite to what Node-RED does - all buffers (or tabs) are visible all the time (in the form of the tab bar) and I only have one frame (since I can only view one tab at a time). And there is only one window with exactly one frame.
The question is: has there been any ideas around having multiple tabs open on the same screen? Basically is it possible to have multiple Node-RED tabs open in the same browser tab is what I'm asking!
I can also hide tabs to make the Node-RED tab-bar smaller but then I have to got to the inspector tab in the sidebar tab-bar, find the tab and then unhide the hidden tab.
And there aren't (or better said: none that I use) shortcuts for making this simpler.
I can see some benefits while refactoring flows for example. That you can drag (or copy/paste) parts of a flow to another tab, without having to leave the original tab over and over again. Because now copy/paste is limited to a single flow editor (and export/import results in more overhead).
But I think it will also make some things more complicated. For example when I am in my dashboard D2 sidebar, and I press the "focus" button for some widget. Then the corresponding ui node in the flow will be selected/focussed. Not sure if you want the flows in all your frames to start focussing on the same ui node? Or when you go the "Search flows" menu item, that all your flows in all your frames will navigate to the searched in the flows in all the frames. Or do you do such stuff only for the 'active/selected' frame perhaps?
And when you double click on a node, then its config screen appears. So I assume that the config screen windows should stay modal on top of 'all' flow editor frames? Because otherwise it become confusing to which node the config screen belongs.
And all the actions for selected nodes (e.g. align them), are those then applicable to the selected nodes inside the currently selected frame only?
And of course you need to keep the flows in all frames in sync, which also makes the code more complex?
That's what coding is all about: making the complicated things seem simple. A dating app has a simple swipe left and right action - super simple. What that represents in reality is going up to a potential partner, beginning a conversation and then asking them whether they like one or not. And then either reject or happiness.
So someone came up with swipe left and right, and now dating is super simple ... and rejection doesn't happen - you are only informed if someone likes you, not when they reject you. So rejection becomes either: the other person isn't online or they rejected. (Sorry for the sidetrack!)
No that won't happen! In my Emacs analogy what would happen is that a search would be limited to the "frame" you are in. So in my Emacs, this is how search works:
In a frame I do a C-s fubar - I begin to search only that buffer
I then do C-x ww and I switch to the other frame within the same window
I then do C-s C-s and begin to search for the last search term (i.e. fubar) in the buffer of this frame
I then do a C-x f - this moves me to the other window and to the first frame (the last frame I was using in that window)
I then do a C-s C-s to search for the last term (i.e. fubar) - so now I'm searching the third buffer in the second window
So the search is limited to the frame I'm in and is never global. But it's a case of using shortcuts to navigate between separate frames and the search remains the same.
Emacs would open a new buffer which would continue the config details. Everything is a buffer in Emacs, even the help pages. But buffers have all the same functionality, i.e., search shortcuts or copy/paste functionality.
But yes this might be a modal above the "window" which currently has focus.
Of course, but imagine how complex it is to build a visual programming environment that runs in all browsers, that can seamlessly deploy to a server and handle millions of messages per second? It has amazing features that prevent users from deploying broken code, with reminders and friendly messages in the editor window to provide details of the mistakes. Just to mention a few features.
Oh no, please continue spreading info like that around.
Love it. I couldn't agree more with your theory!
I met my wife before smartphones existed, and it indeed wasn't that easy in those days to swipe her in or out my car
And if anybody wants to respond about this, please create a new swipe-related discussion. Otherwise the proposal from @gregorius will get lost in the dating related stuff
Yes but - if I understood correctly - you start your search (command line) within one of those frames, so it is rather obvious that it will be executed within that frame. But in Node-RED you have the header and left and right sidebars. If I click in my dashboard sidebar on focus, I somehow need to be able to tell it in which of the current visible frames my action should be executed. I assume you have some kind of border around the active frame, so that you can see in which frame you are currently working?
Is such kind of stuff somehow related perhaps to the new multiplayer (which is an ongoing epic)?
But in Node-RED you have the header and left and right sidebars.
But only one flow tab is open, so I could assume that only that tab would be searched. It’s because the search also searches config nodes that don’t have a tab representation (only a sidebar representation)
In emacs the menu bar is highlighted to indicate which frame has „function“ focus, I.e. upon which frame the functions will apply to.
But that’s the same as the open tab in node red - it indicates which flow I’m working on.
P.s. no offence was intended with my dating app analogy, my apologies if offence was taken.
That reminds me that I did create myself a scratchpad sidebar node, I.e. shown as a tab in the sidebar.
The scratchpad node only contains text areas where I can paste text into I.e. from function nodes code. I can create as many text areas as I like and they are stored in the flow (the node having a config part). I can also compare text areas if I have duplicate code somewhere.
The use case is that I go to one flow tab, copy some code or multiple bits of code into my scratchpad and then switch to a different flow tab where I copy code from the scratchpad - this reduces the number of times I have to switch back & forth between flow tabs.
I can also use the code in multiple flow tabs or wherever else.
This is the symptom I’m talking about - how to avoid having to switch flow tabs too often. Or perhaps what is the best and simplest way to navigate through many flow tabs.
Yes that is indeed a nice use case. Recently I had started migrating my old dashboard to the new one, and had to do a lot of refactoring in my flows. And indeed a lot of digging through the tabsheets, going back and forward between the tabsheets. Although I have to admit that I don't know all the available flow editor actions, so perhaps there is already a solution available.
Perhaps it helps if you create a mock screenshot with paint of how your proposal would look like. That might perhaps attract more folks to your discussion.
Oh absolutely not. Please continue with such nice analogies. That way I keep being focussed
I would if I knew what it could look like I would!
Also if this isn't of interest to other folks, then it's an indication that this is non-problem. Probably for most people this isn't an issue.
And that's why it's a non-problem - how many people literally do this in Node-RED? 0.0001% of users probably So it's not worth implementing anything for which there isn't enough users, even discussing possible implementations makes no sense.
Ironically this issue/idea was inspired by someone who isn't involved in this forum but saw a potential problem in their usage of Node-RED - so there is a grey-zone of users that are using Node-RED and having issues but who aren't here in the forum. So perhaps we're at 0.001% of users!
So it's not worth implementing anything for which there isn't enough users, even discussing possible implementations makes no sense.