I have a group with just two text nodes side by side. The group is configured to be size 6x1.
Each of the two text nodes are configured to be 1x1.
On the dashboard the text nodes occupy a 6x1 strip as expected but there is also a blank area of about another 6 rows below the text.
In the DB2 layout, when I drag this group, it draws a frame around the whole larger area.
Why is my group larger than the 6x1?
Select the text nodes, export, and paste then here please so we can see what you mean. A screenshot showing what you are seeing might also be useful.
First though, make sure you are using the latest version of the dashboard.
Do you have other groups on the dashboard too?
+1 for a screen capture
I’m using Dashboard version 1.26.0
Yes, I have several other groups on the page. One of those groups is exhibiting a similar issue.
Here are the text nodes in question:
text_nodes.json (3.6 KB)
In future please when posting flows see this post for how to paste inline rather than attaching a file - How to share code or flow json
What to you expect to see in that space? The group to the right is taller than the first group. The groups are organised on a grid system which forces the third group down so the top is below the bottom of the second group.
This unfortunately is a bit of a limitation of how we currently do layouts (CSS-driven, rather than Javascript). The group (Let’s call is Group A) is only 1 x row tall, however, the algorithm used to work out where to position the next group (Group B) places it next to your current group (Group A) because there are still 6 x columns of space available.
That next group (Group B) is significantly taller, and so the group after that (Group C) will be positioned below the bottom of Group B in terms of it’s y-position on the screen.
Do you think it will eventually be possible to achieve a "masonry" layout Joe?
Would it require ui groups to have subgroups?
Absolutely it will be. The CSS option was chosen as it gave us 3/4 layouts very easily/quickly, whilst I could focus on widgets. Layout changes are planned in the near future, particularly around not juyst setting fixed numbers, but having separate width/height options whereby you could say “fill” the width, but fixed height of 2, or inversely, width of 2, but fill the height to max as possible. This will include an update of the underlying algorithm with which we render, although I may introduce it as a new “Masonry” layout option in order to preserve backward compatibility and unexpected behaviurs when updating.
As a side note, I’ll be diving into the Chart migration to eCharts today, which will also unlock a lot more great functionality with charting in Dashboard.
2 Likes
@john56, if you make the group much wider (wider than the max display width likely to be used), then it will force the second group to go underneath it rather than beside it, which may be better for you.
Alternatively, move the buttons to the top of the second group, rather than being in a group of their own.
Have you decided whether you will be using the canvas or the SVG renderer Joe?
I had defaulted to the canvas renderer - but I’m open to opinions!
I’ve made the groups 6 units wide and I was hoping to be able to pack the groups in neatly on my computer screen which is 12 wide. I see now what is happening. It appears that groups occupy the same vertical size left and right on my screen. As you suggest, if I make the group 7 units wide it occupies the entire width of the screen but shrinks to just 1 unit high.
I think I can live with that.
Thaks for the response.
I think that if you put a taller group on the left, it can pack multiple short groups to the right of it, but not vice versa.
Might be wrong!
Also if you only ever view the dashboard on a full width screen, the Fixed layout might give you more control over group placement. Again I'm not sure because I've not worked with the fixed layout
1 Like
Looks like they totally revamped the SVG renderer and it is now a lot faster. There is some info in their docs about the advantages and disadvantages of both. However, the SVG version is easier on memory for mobile devices according to them. At one point, the canvas renderer was better to humungous datasets, not clear that is the case any more.
I don't use D2 much of course. 
However, my preference is for SVG since folk can further tweak using CSS and JavaScript should they wish to. Not sure that is as easy with a canvas.
Thanks @jbudd I’ve fiddled with the fixed layout and it’s not much different in my case.
I tried it in a basic eChart ui-template node and it gives much sharper text and image all round.
For those interested just use
this.chart = echarts.init(this.$refs.echart, null, { renderer: 'svg' })
2 Likes
It is also possible to tree-shake the echarts library if not all charts are needed. When doing that, you can also ditch the other renderer.
The full echarts minimised library seems to be around 361kb over the wire (1118kb unpacked), ObserverHQ's Plot + D3 is 64.8kb+95.8kb = 160.6kb (209+280=489kb). So echarts is over double the size of Plot.
Plot outputs SVG only.
1 Like
