Some adjustment issues

[piranna]

I'm using a 1024x768 (125x47) terminal and I'm getting some adjustment issues on the dashboard demo:

As you can see, the bars chart bars gets too wide, so it wrap itself. They should use Math.floor() instead of Math.ceil() for adjustment. Also, there are empty lines between widgets wasting screen space, and finally in the progress bar the background don't get filled under the overlay text, being the background filled all or nothing.

[yaronn]

Thanks @piranna !

I agree the demo is not "responsive" and some of the elements have a fixed width which makes them not adequate for some resolution.

WRT the bar chart, I think the issue is that the default width in bar.js is 6. Try to change it to 3.

There is a defect in the progress bar that when it overlaps with text it does not color the background of the text. Not something terribly hard to fix, just didn't get to that yet.

Also in your screenshot the chart values are filled with questions mark. I assume this is because you are on windows and do not have Braille fonts. You could try in a Linux VM to get a better view (or install Braille on windows but I have not found the source for it yet)

Yaron

[piranna]

WRT the bar chart, I think the issue is that the default width in bar.js is 6. Try to change it to 3.

I'm fetching automatically the code, how could I modify it, doing an ad-hoc fork and using it for testing? Where should I change it exactly?

There is a defect in the progress bar that when it overlaps with text it does not color the background of the text. Not something terribly hard to fix, just didn't get to that yet.

Ah, ok :-) As a suggestion, when you look at it, you would try to use some vertical block Unicode characters to get a better progress bar... A lot more complex, but the eyecandy would be awesome... :-D

Also in your screenshot the chart values are filled with questions mark. I assume this is because you are on windows and do not have Braille fonts. You could try in a Linux VM to get a better view (or install Braille on windows but I have not found the source for it yet)

In fact... it's a linux VM! :-P It's a screenshot of a running NodeOS instance :-) Linux console in text mode is not able to show all the Unicode characters (only by using framebuffer). I've just crafted a psf font based on Unifont that includes the braille patterns (although not the Unifont ones but a cleaner alternative I've crafted) and some more graphic symbols, when it's ready I'll publish it on NodeOS repository. At least, the test I've done on my Ubuntu machine show it's working and it's pretty nice... :-D

[piranna]

I've been thinking about the empty lines and though a solution would be to round the accumulated coordinates (position) instead of the widget size, this way instead of rounding all of them to the floor being conversative so widgets doesn't overlate, rounding the accumulated coordinates some of them would be smaller than their correct size (due to floor rounding, like as this moment) but other would get one more row/column (round to ceil), filling all the blank rows and columns. The same maybe it's possible to be done with the cart bars, but maybe in this case the better is to round all of them to floor so they are all of the same width.

[yaronn]

WRT bar charts, @flatiron32 has been doing some work around it recently, you should try the latest version from today.

Great idea about vertical block chars, let's see when I get time to implement that.

Not sure I understand the idea about line spaces. Would accumulating actual positions rather than width could mean that some widgets on the same "level" will not be aligned?

If you want to change the bar chart just clone the repo and the code is in /widget/charts/bar.js. Layout code is in /layout/grid.js. Both are very short. If you come with something interesting please send a PR ;-)

Really looking forward to see a dashboard screenshot with your font!

[piranna]

Not sure I understand the idea about line spaces. Would accumulating actual positions rather than width could mean that some widgets on the same "level" will not be aligned?

I'm not talking about width but about height. I don't believe they could get not aligned if they are not too complex schemes, and since the split is done by "all equal", then probably will never be. An example about what I'm saying: split 10 rows for 3 widgets. 10/3 = 3.33, so widget heights will be [1-3.33], [3.33-6.66] and [6.66-10], that by adjusting the acumulated row to the nearest one (prev+1 for begin and floor() for end) will result in [1-3], [4-7], [8-10], giving sizes 3+4+3=10, while by simply round()or floor() the widget size from their corresponding position would give [1-3], [4-6], [8-10], leaving the row 7 empty.

Charts and layout could be made more responsive, yes :-) Maybe removing fixed sizes and using proportions, similar to what I said in the previous paragraph, and maybe combining it with horizontal scrollable boxes for when they are too tiny, for example :-) Unluckily I don't have time at this moment :-(

I've been able to use the font on my Ubuntu machine :-) but I can't make it work on NodeOS, setfont is difficult to compile and later it didn't worked don't know why... :-/

[yaronn]

Thanks @piranna, that makes sense and I will add it to the pipeline. Please keep this feedback coming, great ideas!

[piranna]

You are welcome :-)