Could you take a look at the fix? Is it better for you?
@Terdious I left you a review:
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.
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.
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?
That works for me ^^
Remove it then, just keep the button at the top, that’s enough for me and I think it works better 
1 Like
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!!
I’ve replied to your comment:
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!!
And if not, why not a regular flexbox?
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) › ^^
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)
1 Like
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
1 Like
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!!
Actually, I personally think that makes sense, especially as you say when there are already many large blocks.
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…
.container {
max-width: 90%;
}
2 Likes
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 ?
Pierre-Gilles had suggested I use an extension like CustomCSS that allows automatically modifying the CSS when the page loads.
2 Likes
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 ^^
1 Like
Thanks @Terdious for the fixes, it’s much better like this
It’s much cleaner, we went from a big PR in terms of code to practically nothing, it’s perfect 
Less code = fewer bugs!
I have a tiny comment on a very minor thing but the rest is fine with me :
2 Likes
Hi @Terdious 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!