The list of FlexDash nodes in the sidebar keeps getting longer and longer... I'm wondering whether I should switch to using a single "FlexDash Widget" node where one would then select which widget one actually wants. One benefit is that the selection could have a little richer UI. I could perhaps leave a couple of most frequently used widgets as separate nodes, e.g. stat, gauge, button. Thoughts?
@BartButenaers you mentioned another project that does the above, can you remind me? Also, if you could post a couple of screen shots of how the selection looks like in the flow editor, I would appreciate.
The guys from node-red-contrib-google-smarthome recently replaced their long list of nodes by a single generic node. In a dropdown you can select the type. Of course you could also create separate npm packages, so you can install only what you need. But perhaps that is not easy with your generator...
It's not really an issue with the generator, in fact, the generator makes it easy 'cause I can generate all kinds of crazy stuff... The issue is that currently all the widgets are pretty generic and basic, it's not like half of them are special-purpose and only few people might need them. The whole experience, also when importing flows, would be pretty awkward if I split them up arbitrarily. Also, if you need just one widget from each repo you'd end up with all. So it would not help users that have large varied dashboards at all.
IMHO this is something Node-RED should solve . If that's not gonna happen, well, I guess multiple projects will just have to create a custom "sub-palette"...
I took some screen shots of how google-smarthome does it:
Since I already have two tabs for the FlexDash widgets I would put the selector on the 'general' tab and then the 'widget props' tab would show the appropriate properties. Ideally, I'd create a more visual selector that groups widgets into categories (inputs, tables, plots, text, ...) and that displays a thumbnail of sorts.
"Hack the colorPicker and s/color name/widget category/ and s/color swatch/thumbnail/", haha...
If you need to switch to TimePlotRaw for the full uPlot flexibility you can use the widget output to see the options it constructs as a starting point.
...but using any of the flows that I've shared above, there isn't a widget output from the 'Time-Plot' node?
The proper fix is probably to (a) enable the capture of clicks on the plot, produce output messages for those, and then add a output message as described in the help. Or, to see the opts, have a button in edit mode to display them.
Are you trying to customize something in particular?
I wanted the option to remove the line markers (the small circles at every data point).
They can be useful for some charts, but can be distracting for others.
It would be good if a basic example could be added to the 'all-widgets' example flow, so we know the general format to start customizing from.
I'm just using the default behavior, which is to draw the point markers until there are a certain number of points (20-ish?) and then they go away. Customizing that may not be so trivial as you may have to pass some function into uPlot via the opts...
Have you looked into the uPlot documentation (sparse) whether this is mentioned at all? If not, the next place to look is the uplot.d.ts typescript data type definitions file, there you can see what you can pass in via the opts and then work backwards.
LMK if you're not getting anywhere. (Perhaps start a separate thread on how to customize the time-plots and post what you tried and what you get...)
'been playing with some fun stuff... I have a table with the DHCP leases of all the devices on my network. I want to click on a row and see the Wifi info for that device. Sounds like a use-case for a pop-up, right? Why can't dashboards have pop-ups? Time to add them!
It all still looks like and there are missing pieces left & right, but the basic functionality is there. The pop-up content is a PopupGrid and as the name implies it functions just like a standard grid into which you can place panels and widgets. The only difference is that instead of being in the flow of a tab it's hidden until its show prop is set to true.
In FlexDash the whole thing took less than 30 lines of code. Sadly the Node-RED part took a lot more: the popup grid has to be a part of the flexdash container config node, which is OK, but config nodes cannot be wired into a flow to get a {show: true} message. So I had to create a flexdash ctrl node that gets associated with the grid and that receives the message.
I think a PopupPanel might be interesting too, the difference being that it could be non-modal for smaller stuff, like a color picker or something of that style.
My second guess: are you the CTO of a spinoff that Santa Claus has started, to support our community? Better than the original again of course
Will do two proposals, but only about popup menus (in a desparate attempt to not look too greedy...).
While @Steve-Mcl and I were developing the SVG node, we also were building meanwhile the node-red-contrib-ui-contextmenu node. Because we wanted the users to be able to right click on an SVG element, and then be able to select a command from a contextmenu. For example to turn a light bulb on or off.
But we developed the contextmenu as a separate node (i.e. not part of the svg node) to allow users to use it for other ui nodes. Which they also did afterwards...
As a result, some times afterwards we needed some kind of standard. Indeed if you want some node-red-contrib-ui-xxx node to support our context menu, it would be interesting if all ui nodes send the clicked coordinates in the same message output field. Otherwise users need to start putting Change nodes in between the ui node and the ui-contextmenu node, to move the clicked coordinates in the output message to the position where the contextmenu node expects them.
So I had started this discussion: near the end you will see that we had some kind of agreement among the ui developers of that time. Although there is room for improvement in that agreement, because very recently I got an issue for the SVG node where you can see that the current coordinates are not optimal yet.
If you could manage that every widget could send the (correct) clicked coordinates in its output message, that would be very useful! Similar to how you arranged that every widget now has a topic field in its config screen. Because then we are sure that all widgets do it the same way. If this would become the responsibility of the Flexdash framework (instead of every ui node), that would be awesome!
And I don't know if vuetify supports a contextmenu out of the box? Because the current contextmenu node was based on a Js contextmenu node that Steve had found. But (see this recent issue) that original library is even removed from Github, so there is no support anymore. Moreover in the past there were problems anyway with that library, when crossing the perimeter of the window: Steve managed to solve it by adapting our clone of that library (see here). Just to tell that this node contains quite some logic, and would be nice if you could find a popup contextmenu supported by the Vuetify community...
Hi Thorsten
The FlexDash is a wandful project for me. I had try the FlexDash demo page and everything work fine. And I decide to migrate my dashboard project to FlexDash.
Current situation:
If I create the flexdash dashboard inside Node-Red @ flexdash/node-red-fd-core-widgets, everything works fine. Due to the config file is save to ~/.node-red/flow.json
However, if I run FlexDash from pre VueJS env, "npm run serve", the front-end data would lose if I refresh the web page. Due to the config didn't save to backend server. The problem is, how to save config to server side?
Scenerio 1: If I want to connect to node-red backend, such as 127.0.0.1:1880/flexdash/io. No corresponding backend handler to deal with this request. What should I do to bridge pre FlesDash vue files with existing Node-Red backend?
Scenreio 2: If I want to connect FlexDash to private backend server implement by python. What shoud I do?
Here is my assumption below, am I right?
- Step 1. Import socket.io lib in python server
- Step 2. Inside socket.io, handle request to the topic $config to save or load config.
@tve I think there is plenty to improve. For example, rather than implicit declaration such as msg[somefield] we can use TypedInput msg. also I think that we can remove the text description under each of the fields (save realestate), then use TypedInput for much of the fields. This way the editor is concise. At the moment the editor scrolls way too deep and the requested fields are pretty self explanatory in my opinion or rather the docs will suffice. What do you think ? I will probably find sometime over next weekend to go through and create the inputs if needed ...
I think I would solve the context menu somewhat differently in FlexDash. I would create a ContextMenu component (not widget) and then use that in my widgets. This way you have "full control" over placing the context menu and don't need to feed coordinates through Node-RED. I know this sounds a bit mysterious right now 'cause the tools to develop your own widget or component aren't readily available, but we'll get there.
Vuetify does have support for menus, overlays, dialog and that type of stuff. It's an area where I'm still having some difficulties with the positioning options, but I hope they get resolved soonish.
I'm glad you're enjoying FlexDash! I don't really understand what you're referring to in your question, though. How are you running FlexDash? Is this related to Node-RED? Maybe you can explain what you're trying to achieve?
Well, I'm rather fond of these little descriptions. They're much more user-friendly than letting the user guess and they take up almost no space. Even in simple widgets like Label I find the options non-obvious. E.g:
How would you know which values are acceptable for these? How many people would know that align is vertical and justify is horizontal? What's the range for weight?
If the community finds these descriptions annoying I'm open to deleting them, making them on-hover or placed behind a icon.
Interesting issue. The reason the msg.data version doesn't work is that msg.payload remains set to some useless value and it overrides msg.data. The code I have is something like:
flexdash_message = Object.assign({}, msg)
if (msg.payload) flexdash_message[payload_prop] = msg.payload
where payload_prop has the value data for this widget. The improvements I can see are:
add some warning if both msg.payload and msg[payload_prop] are set
remove the mapping of msg.payload, i.e. none of the widgets would do anything with .msg.payload
instead of allowing both msg.data and msg.payload just restrict to msg.payload only
I'm inclining myself to #3 even though it breaks my heart that one wouldn't be able to set the prop labelled "Data" using msg.data
By convention, msg.payload is generally accepted in node-RED as the channel to pass msg's through the flow, so yes option 3 looks a good choice, and would also be familiar to the node-RED community.
NO... They are AWESOME!! I vote to keep them for sure!!! Most of us use rather large monitors with good resolution when we are doing development work... so realestate savings is not an issue when editing flows.
That's what TypedInput options for when the attribute hasValue is false. I was thinking of using TypedInput Options, and so it is a selection of Top/center/Bottom for the Align field for example.. This will be a dropdown defined list of values rather than a user types a value...
for me the descriptions are distracting but that's how I am !, I just like to see less in the screen or it becomes little much for my tiny brain but I understand it is not for everyone too if the values are dropdown list in my view the descriptions become redundant. Another reason is that Node-RED for good or bad has now matured a particular pattern , and when people see text descriptions, they tend to read it thinking something is different with this node than the standard core ones, which is unnecessary if one is simply following the same core node patterns (if you know what i mean) but they look good though , font and everything is cool I am just saying..
I personally think rather than re-inventing the wheel and have so many different ways.. I am a big advocate of using the core node patterns, the TypedInput field allow you to have a default value and the user can change. so msg.payload is the default, but the field can be changed by user to anything which is great. I will hopefully have sometime to modify a single node and utilise the TypedInput everywhere and see what everyone thinks. The good thing about following those established patterns is you learn them once, and they become just intuitive. the TypedInput field has come a long way in my opinion too (for example they now allow you to embed custom fields inside them)
. If that's not gonna happen, well, I guess multiple projects will just have to create a custom "sub-palette"...
.
I have a table with the DHCP leases of all the devices on my network. I want to click on a row and see the Wifi info for that device. Sounds like a use-case for a pop-up, right? Why can't dashboards have pop-ups? Time to add them!
and there are missing pieces left & right, but the basic functionality is there. The pop-up content is a PopupGrid and as the name implies it functions just like a standard grid into which you can place panels and widgets. The only difference is that instead of being in the flow of a tab it's hidden until its 
icon.
if the values are dropdown list in my view the descriptions become redundant. Another reason is that Node-RED for good or bad has now matured a particular pattern , and when people see text descriptions, they tend to read it thinking something is different with this node than the standard core ones, which is unnecessary if one is simply following the same core node patterns (if you know what i mean) but they look good though , font and everything is cool I am just saying..