I created an editor inline gauge however there are some interface elements that are rendered underneath my canvas output, the mouse cursor changes to the move cursor when I mouse over however I can't click or drag on the node.
In my opinion it would be a great feature to allow nodes to have custom display, ui and event handlers that can be done in a standard way. Some other use cases I can imagine would be inline sparklines, a debug node with a list of watched properties, simple stateful or stateless UI elements that can be clicked on the inline custom node to change properties, check boxes, radio buttons etc. It would add the ability for debug and informational displays inline for a flow so a user wouldn't have to rely on debug panel as much. There could be a global or flow context "debug mode" option so these nodes could be shown, hidden or disabled based on the flow running mode. In this way a user wouldn't have to manually click on every debug node to enable or disable.
1 Like
Hi @johnebgood,
Really nice demo!
This kind of feature requests has come up already a few times in the past. But it unfortunately always ends with the axiom "the flow editor is not a dashboard". Imho it would be nice if people that really dislike this kind of nodes, would allow other people to install these ugly horrible looking nodes and mess up their user interfaces 
. Everybody happy...
One of my most favorite nodes is node-red-contrib-image-output, which unfortunately also needs to hack into the flow editor to get things done. Would have been nice if you could this kind of stuff by e.g. adding some callback functions in the html file of your node.
Of course I understand that this will require a lot of discussions to get a useful look and feel. And that implementing this feature in the core might be a significant effort. So it’s easier for us said than done. All respect for that...
Good luck with this!!
Bart
1 Like
Hey Bart.
I am happy to be corrected but it is my understand that the issue is more that there was never any design and discussion on formalising an API in the core for permitting these kind of visual customisations.
I've not checked, but there may be an existing design note?
Typically, if a forum discussion around a core feature request heads in the right direction, the op would be invited to open a design discussion here
Let's see if this thread can lead us there 
1 Like
@BartButenaers - Indeed - the editor is not a dashboard. But I don't think we ever disallowed people installing " these ugly horrible looking nodes and mess up their user interfaces ". If someone does want to create a node that does that it is up to them - eg see @Steve-Mcl's Image tools or Mike's Data View tool
3 Likes
Indeed, and I could see that a sparkline node would be occasionally very useful indeed. The full chart in the data view being a bit on the large side for me.
1 Like
Mean Dave. Mean. 
I do think some visualisations are important to developers, at design time and for debugging and system status monitoring etc. and, if we're to be brutally honest, as useful as the debug node is, it's just too disconnected from the thing we want to debug. Not only is it in a side bar (disconnected) but the message is effectively 2nd hand at the point of viewing
I welcome the day we can offer node Devs an official means of offering these visualisations (I wish I had the time to progress a design - any spare time ATM is soaked up by the physical world or trying to get resolution on improving subflow env var handling for improved RAD and OEM capabilities)
2 Likes
That was Bart’s comment not mine ;-). And yes, I do agree that debug is due an overhaul in some manner. We have talked before of an inline node to prevent forking for one. An inline one could have several modes like sparkline, text, gauge, leds.
I think it is/was only the comms api to the editor that was never formalised. But then I don’t think we have actually changed/broken it over 10 years. So 
2 Likes
Hey Steve,
A bit of delay here. While I was writing my feedback this morning, suddenly I realized that the familly around me had other plans
Ah that would be good news. From the discussions in the past I had concluded that it was not only due to a missing API, but that it was not the intention to develop an API. But then I need to start polishing my knowledge of the english language. Case closed then...
Yes I totally agree that a good discussion here is very useful. Since the demo from @johnebgood already shows different ways demonstrated to achieve it. Hopefully a decent design agreement will be born here...
Evening Dave,
I really need to start polishing my English. I didn't mean that anybody would prohibit me from using these fancy styled nodes. I meant that it would be nice if we could have a way to develop such nodes in a standard way in the future, without having to bang our heads against the wall and invent some hacks that might be broken in the future. And if that standard way of working has some limitations, that doesn't matter to me: I think it is better to have a standard way of doing this, instead of having nothing at all. Then at least of all of these fancy nodes at least would have a bit of similar look and feel. Otherwise it indeed might look very quickly amateurish.
Yes completely true. But a wise man ever told - at the moment Mike's node was released - that we would have to use it at our one risk . Such a way of working is not really fun for developers, because you spend your free time hoping that you have made something that will last long...
1 Like
that is always true - even for the core... and they keep changing OS support, Nodejs support, etc under us - and so indeed even with best intentions, things may have to change in the future - eg see Dashboard v2.
The warning there of course is that the API, being undocumented, had the potential for change and we don't have to tell anyone, but as more recently noted... it hasn't actually changed at all (yet :-)...
And in fact I forgot that indeed it did get written up - @node-red/runtime_comms - Documentation
mea culpa... sorry about that.
From the point of view of a "design" - I'm not clear exactly what is being asked for... apart from the comms above. Is it a prescribed look and feel for an extension panel with (say) a div inside it that the developer can populate ?
1 Like
With the hopes of kicking off a discussion for clarity. I can think of a number of things that might be useful additions without, hopefully, being too costly to implement.
These would apply to any node:
- Extending the node status display to allow for more content - perhaps even full HTML. Since that is, I think, already its own element, it should then be possible for people to style it in various ways. However, probably needs to have a click handler available - at least a way to double-click to open the node's config panel.
- As above but a new panel. Might be even easier to do than the above?
- The ability to have HTML and/or SVG content in the node display itself. I suspect this would be more complex to arrange but would also be the most flexible?
I think these would be my preference personally, in order of preference mostly due to ease of development rather than any other thoughts.
However, the following might apply to a debug node - either new or existing (personally I think I'd prefer the existing one to be extended):
- Add option for the existing debug node to have an output allowing it to become pass-through - in theory, this should be really easy to do I would think (I'm afraid I've not looked at the node's code so I might, of course, be completely wrong).
- Add a new debug node that is only passthrough - I can't really think that this is sensible ... ?
Of course, the items from the 1st list could be made to only apply to the debug node(s) but that would be quite restrictive I personally think.
Anyway, my thoughts for what they are worth.
2 Likes
Not sure extending status would be good, as then every single node could turn into a visual indicator-fest free for all.
Having pass through as an option would mean losing the debug on off button when in pass through mode - (and yes I absolutely do not like nodes with both wires and button) so for me it's one or the other.
I tend to think of this as an indicator node rather than debug so I think a separate node would be more appropriate. (IMHO)
4 Likes
I have given this some thought over the years. I would love 
to see nodes have more capabilities including better UI when having both input/output AND buttons.
Clearly, the current design makes this look awful (wires passing through the buttons - yuk) but I'd love to see it addressed with a UI refresh.
One way of supporting this would be a node redesign (
) with the buttons moved internal to the node body, permitting input/output wires to connect to the edges without overlapping the buttons. Another solution would be context menu or hover popover to provide access to the button(s) when an input/output port also exists (but this is much less friendly/intuitive)
There is another school of thought: asked several times over the years - is all nodes having a "mute" and/or "passthru" capability. I.e. a means of simply turning off the messages or bypassing internal logic processing. Having this "passthru" capability would simplify the design of an inline debug. Having this "mute" capability would also be a neat way of handling the age old question "how to I stop messages passing through a node"
3 Likes
My issue re mute is that there are in fact very few instances of nodes where just passing through a message (ie muted) would still let the flow run - after all the main purpose of most nodes is to change the message in some way. Yes there are going to be a few - (eg debug as we are discussing) - but not many others.
So in my mind making it an option for all nodes is a bad idea.
2 Likes
We can always hope! 
OK, decent point. Though adding an action menu might mitigate it.
Actually, that is probably a decent starting point anyway. And it reduces the scope of the issue. A separate node could possible start by using less- (or un-) documented API's to begin with and could start as a separate Node package so that the capability could be deployed quickly and maintained independently.
Then internal API's could be ratified and documented to allow other nodes to use them as time permitted in the core development schedule.
Raising, incidentally, one of my own pet dislikes since you aired your own - how many nodes are in the main Node-RED package which severely limits the ability to get improvements and fixes deployed and perhaps even more importantly, makes it very much harder for other people to contribute fixes because they have to know how to update the whole of Node-RED rather than just a node or two.
3 Likes
So, assuming a separate node ...
Can we decide whether a display should replace the normal node visual or whether it should be adjacent to it?
My personal preference would be for the display to be adjacent BUT with an option to easily show/hide (that would survive Editor page reloads so that the last setting was always in use).
Not only would that reduce the need to mess with the main node display code but would also allow collapse of the visual which I think will be really important, especially if larger visualisations are allowed.
2 Likes
Thanks for the feedback, I used node-red-contrib-image-output as a base for this! 
I will make sure I give proper credit to that when I release this in the next week or so.
I've been using a power plant/factory paradigm, while there is a control room there are also gauges and sampling points along the process/manufacturing pipeline for people working the floor. I spend all of my time working the floor in the Node-RED editor for my flows so having informational output at glance would be helpful. It's not always fun going through the debug console to see what isn't healthy.
So yeah, I'm hoping this can be a conversation starter around standard API's to allow a developer to easily do whatever they want in the editor. Regarding "the flow editor is not a dashboard"; why can't it be? Imagine trying to create a flow without the debug output. The debug window is the terminal "console" to the flow; why can't that console be modernized to have graphical representations and controls? There's the current debug window, maybe there could be an html debug view that takes a list of sampling points along the flow and assembled the overall flow "dashboard" view based on the sampling "debug" points. What if the new junction nodes could configured as sampling points?
Ok, feeling like I'm just producing word salad at this point going to take a step back and make this gauge as good as it can be with the current limitations. Thanks for the feedback everyone.
~John
3 Likes
Yes I thought so, because some others also did that.
But you have taken it to a next level.
Because until now I also had the idea that the visual content above or below the node, but you also had a third option INSIDE the node:
I have to admit that I really like the content inside the node, because it looks very compact. Of course that is only my personal opinion and probably others think different about this. And it has some disadvantages to show the content inside the node:
- Not sure if it can easily be enlarged. Currently with the image-output node we can enlarge the image, which is handy if you want to zoom live in on your camera footage (without deploying the flow).
- Like @Steve-Mcl above mentions, you need a way to open the config screen of the node. When you show the visual content above or below the node, it is very clear that you have to double click on the node. But when you show the content inside the node, that is not obvious. Because people might expect that clicking on top of a gauge, does something with the gauge (instead of opening a config screen). Although of course we might have a single click that belongs to the gauge and a double click that opens the config screen. But not sure if that works also on a touch screen or all OS'es...
The most open way of working would be to allow the node developer to specify where the content needs to be displayed (above, below, inside), a bit similar to how we can specify where the node icon should be displayed. But I don't want to become greedy, so it is all fine for me. I am already very pleased that we have this discussion...
I really hope you stick around in this discussion...
Some time ago I was experimenting with video surveillance in Node-RED. Drawing on top of the camera images (e.g. bounding boxes, masking areas, ...) is very cpu intensive on a Raspberry. Therefore I created a fork of the image-output node to support SVG. That way the browser can do all the drawing, which moves all the cpu intensive drawing work away from my Raspberry. This way I can e.g. very easily check if my object detection developments are working fine or not.
But it is all custom code dedicated to one single node. It would be very nice if SVG content would somehow be supported out of the box in the node appearance, so that you don't need to reinvent hot water for every node where you want this kind of stuff 
3 Likes
I don't think it is really "inside"- I think it is just on top but happens to be the same width (or is fixed to the same width).
2 Likes
Correction. Of course also a fourth option 'hide' to hide the visual content, so that your node looks like a normal node. And perhaps that this is the default option, because 99.999% of the nodes will show no visual content anyway...
1 Like
Yes, just rendering over the top at the moment, as soon as the flow is deployed the gauge isn't rendered so the nodes can be positioned, they only show up when data passes through them. I am also adding an option for round or square options.
1 Like
