Flow control menu on tab

Granted, I've only been using NR a few days and I've got a ton to learn but it seems a glaring omission that there is little control over a flow's operation. What I expected to find (and I suggest right-clicking on the flow's tab) is a menu with Save, Revert, Delete, Start, Stop, Enable, Disable, and Pause. NR has amazing capabilities and I'm already planning on making it my center for processing and display but I feel it's archaic to have to get into the flow's properties to dis/enable it and that a Deploy button starts everything. How about removing Deploy altogether in favor of the items I'm suggesting in a menu?

I've searched the topics here and found no rationale for the current way it operates but I have seen a few frustrated users over the way it now works.

Thanks for listening

The fundamental model of Node-RED is that everything that is deployed is running unless it is disabled.

You make a change, you deploy the change.

The deploy button is how updates are made to the running flow configuration.

The ability to disable a flow (or node) is a relatively new feature in the project's 7 years of working like this. Some of the UI around it can continue to evolve as we get feedback. You say you have seen lots of frustrated users ... I can't say that's feedback I'm particularly aware of. There has been the very occasional question about it, but nothing to warrant throwing away the fundamental model of the deploy button.

So thanks for your feedback after a few days of using it. It's clear that the model you expected is different to how Node-RED actually works. I'm sorry you find it archaic.

1 Like

Thanks for the reply, @knolleary. To set the record straight, I didn't say

I said

Please don't misunderstand because I also said

I sincerely hope my suggestion will be implemented at some point. Meanwhile I'll conform because I have no other choice :wink: At least not short of diving in and making the changes myself which I would gladly do if I were familiar with Node... and 40 years younger.

What would the difference be between start/stop and enable/disable and the difference between pause and stop?
Is there a difference between Save and Deploy, as far as the current tab is concerned?

The other thing to bear in mind is that currently we also have a "few" tablet/mobile users - and right click is not really an option for something as fundamental as deploy.

Hello and next time please leave the pin in on your hand grenade when you lob one into here :slight_smile:

But, you raise some interesting issues

Leaving aside ergonomic diff between double-clicking/right-clicking on the tab to do stuff like enabling/disabling etc as that's just cosmetics

I (and many others) use NR to run long-running tasks (24/7 ones) and we've grown to like the concept of editing and then using the one simple button (Deploy) to stop the background program running - reload current flows and then restart again.

[EDIT] When you hit Deploy - you have several options to restart everything or just the bit you've just editied[/EDIT]

That's actually quite a good feature usually not available in other programming IDEs

So I think having to do separate Save then Stop then Start isn't an improvement over that in terms of whole running system

Just being able to stop/start/pause one flow (while all others carry on running) could be useful. (See note below)

I'm not sure how easy (or important) this would be able to acheive

If you stick gate nodes in your flows - then you can effectively do this

As an example, this Alexa flow of mine has them in so I can test out stuff without the final result messages leaving the flow.

PS I'd forgotten that I'd closed my gates so that explains why I couldn't pause my SkyQ box from the kitchen 30 mins ago :slight_smile:

Let's use systemd services as an analog. Start/Stop does so immediately whereas Enable/Disable controls what happens on startup.

Save would just update the backend with the current flow changes whereas Deploy does this AND starts not only the flow you're working on but ALL flows that are not disabled.

Doesn't the "hamburger" menu fit this? I'm an Android guy and don't know what IOS uses for the purpose.

Being new to NR has both advantages and disadvantages and I understand that long-time users just know how to work in it. We humans have a built-in resistance to change even when we can see the benefit.

@cymplecy, thanks for the laugh and edification. I, too, will have most everything running 24/7 and wouldn't want running flows to be affected in any way while I'm tinkering with a new, or old, one.

If the background were like systemd, or whatever it's analog is on Windows (Service Manager?), it wouldn't be necessary to stop any flows to start/restart the one currently being edited. But I see where changing the architecture from a "run everybody at once" to managing each individually is like a very large change.

I'm familiar with Netbeans and there you can have several projects in the editor and edit/start/stop/debug them individually. However, you do have to stop them all to exit the IDE and would then run them however you normally do outside the IDE. In many cases it's feasible to leave the project running in the system environment and run another instance of it while working in the IDE.

Before anyone swoons at the changes needed to make NR the same as Netbeans understand that I'm not advocating for that big of an overhaul. I don't see a need for, or benefit of, it in the much more focused environment of NR.

I've worked around, and just a tiny bit on, industrial process control systems enough to know that one can stop/edit/start one PLC and not affect the others unless there is a dependency between them. Is a NR flow not analogous to a PLC?

I apologize if I came off as disparaging the designers or users of NR. My thoughts were of my frustration (and of at least some others) and the desire to improve this fabulous tool/system.

No - but a nice big deploy button does :slight_smile: - the hamburger menu is only one per page - you are talking about right clicking on each tab of which there may be many.

I'm glad of that - for a minute I thought you were wanting to completely change the existing runtime lifecyle model of Node-RED... oh....

As node.js is single threaded then yes the whole runtime is analogous to one plc (which includes all the tabs). It may be better to think of the whole runtime as one exe file... as you also said, once it is running you don't generally get to turn on and off parts of it. The whole point is that it runs headless most of the time - I don't run most of my apps from an IDE. Even when in an IDE I don't generally get to disable methods and calls without going into them and commenting them out.

One of the reasons we resisted even disabling tabs for so long was exactly the reason @cymplecy mentioned... that it is all to easy to disable something then forget you have done that... even worse in a multi user environment where some else may do that for you. If it's always running yo know where you are. If you don't need it - disconnect or delete it... OK we softened on that, and indeed we may still have further to go - but it will be small steps to ensure we bring everyone with us... whatever that direction is.

Can you not set the deploy node to "modified nodes only" then disable the tab and deploy - that should stop that tab while leaving others running.

After I typed all that I realised that that effectively we can do already do everything really :slight_smile:

So maybe it just needs a little bit of UI work to just make things a little bit more explicit

1 Like

Keep the ideas coming

From a UX perspective, we already have the Flow Outliner design which will give a better overview of your workspace contents. That will be a place for in context actions to be made available. Being able to more readily enable/disable things is one of the uses for it.

It would still work on the assumption that you have to click deploy for any changes to take effect, because that's the model we have.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.