Graphics improvements

Development
101

@pierre-gilles,

Could you take a look at the fix? Is it better for you?

102

@Terdious I left you a review:

103

I replied to you about your questions on the PR.

I made the changes to separate myself from the Overkill part, but I’m back to the same point — there’s a particular moment where I don’t understand why I get a bad result:
On some of my dashboards (I have the impression it’s when there are many items), the height retrieved is wrong when the page loads. Then componentDidUpdate takes over and the value becomes correct again. I therefore think it reads the height while the page is not completely loaded
 But I can’t find the right feature. â€č resizeObserver â€ș and â€č mutationObserver â€ș worked, I was happy. And I saw on StackOverflow that it was recommended, but also that it was very fast.

For example here, the console.log gives me 2371 while the actual height is 3385. Once an update occurs, I get the correct value.

image
image679×285 14.9 KB

image
image1903×952 119 KB

Feel free to point me to better approaches if you have any ideas on how to better handle the â€č sticky â€ș position in this scenario.

I pushed the changes.

104

After testing, I have to admit I don’t really see the point of the sticky; when you’re at the bottom of the screen it’s actually quite confusing for the user:

You click, but nothing happens visually.

So in the end, I do question its usefulness a bit ^^

What do you think?

105

That works for me ^^

106

Remove it then, just keep the button at the top, that’s enough for me and I think it works better :slight_smile:

107

It’s done and pushed!! You’re right, I liked it but in the end it’s not so bad like this ^^

Thanks for your analysis!!

108

I’ve replied to your comment:

109

Hmmm ^^ You’re asking me a question here ^^ Actually it was to set the stage while being dynamic!! I was thinking that if one day you increased the display size (that would be awesome ^^) it would make it possible to switch to 4 or 5 columns easily ^^

But indeed, if we stick to three columns it works well!!

110

And if not, why not a regular flexbox?

111

It’s really about keeping as much space as possible for the columns to fill. I switched to percentages:

  const columnStyle = {
    '--column-width': boxesLength === maxBoxes ? `calc(100% / ${maxBoxes})` : `calc(93% / ${boxesLength})`
  };
  const addButtonStyle = {
    '--add-button-width': boxesLength \u003c maxBoxes ? 'calc(7%)' : '0'
  };

But otherwise, never mind, we can stick with â€č col-lg-10 â€ș / â€č col-lg-2 â€ș when there are 2 columns or fewer. The issue only comes up with 2 columns where I can’t do â€č col-lg-(11/2) â€ș ^^

112

Yes yes I’m not questioning how it works ^^

But why not use CSS flexbox to do that?

You have a fixed column: the last column with the button

And 1, 2, or 3 columns that should have a dynamic size that’s just the remaining space divided by the number of columns (and it’s automatic, nothing to code, it’s CSS)

113

Let me add my two cents — I second the idea of being able to make 1 to N columns; it helps define a direction for how to manage columns, especially with increasingly higher-resolution screens. On large screens, three columns only occupy 50% of the page width.

From what I understand it’s built on Bootstrap, a small col-xl-N that depends on the number of columns is feasible, even if it means allowing 1 to 4 for example to keep a multiple of 12. But in my view 3 is still a tad too light on large screens. And the problem with going up to 5 is handling that multiple under Bootstrap — a lot of trouble for little gain. But 4 seems like a good compromise to me.

Another piece of feedback, not on the purely column side, but it would be interesting to have an expansion panel in the editing area for the cards inside the columns. For example, for large cards like charts, if you have 3 or 4 of them, it quickly becomes difficult to move cards. We could simply add a button to the left of the move button that would be â€č Collapse â€ș. Just an idea :slight_smile:

114

So in the end you’re proposing to keep the reorganization mode (« Re-order Â») introduced for mobile devices (or small screens) that @pierre-gilles developed!!

1000020407
10000204071080×2316 162 KB

Actually, I personally think that makes sense, especially as you say when there are already many large blocks.

115

Personally, I changed the CSS to increase the width of the blocks because otherwise, as you say, there’s way too much wasted space on the screen


image
image1919×617 97 KB

.container {
max-width: 90%; 
}

image
image1919×617 102 KB

116

Ah excellent, I just tested it at 80% — it’s really nice.

You created a Dockerfile where you pull the Gladys Docker image and you modify the CSS file each time, is that it :slight_smile: ?

117

Pierre-Gilles had suggested I use an extension like CustomCSS that allows automatically modifying the CSS when the page loads.

image
image624×420 62.3 KB

118

Hi @pierre-gilles,

Thanks for your help and sorry for the initial misunderstanding. The fixes are done, all in CSS and it works very well for me. I also picked up 4 ESLint warnings in the process.

I’ll let you check the PR (and see if it’s what you had in mind) and let me know.

I’m moving on to reviewing the binaries ^^

119

Thanks @Terdious for the fixes, it’s much better like this :slight_smile:

It’s much cleaner, we went from a big PR in terms of code to practically nothing, it’s perfect :ok_hand: Less code = fewer bugs!

I have a tiny comment on a very minor thing but the rest is fine with me :

120

Hi @Terdious :slight_smile: I’m checking in about my last message.

It would be great if this could make it into Gladys quickly — it’s really an awesome feature!