Created attachment 183824 [details] Screenshot of the issue SUMMARY Currently, cards are all sized the same on a given page; this means that if you have a particularly tall row, all rows will be massive. This makes very little sense and makes the UI a lot less usable than it could be. As an example, if you have a lot of partitions that you are monitoring in the "Disks" section (which comes as default), the hardware resource row (CPU, GPU, memory, swap) will be very tall as well; see screenshot for reference. STEPS TO REPRODUCE 1. Have a tall card row OBSERVED RESULT All card rows will have the same height as the tall card row. EXPECTED RESULT Card row height is adjusted based on its content, rather than on the size of other cards. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Sorry, I sent the report before completely filling it in! SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1
There are several modes to choose from for row height. The default is "balanced" which tries to maintain the same row height for all rows that aren't titles. This is done so the rows have a regular pattern rather than each their own size, leading to a more regular page. You're right that this can lead to excessive height for other rows if one row is particularly high. In that case, you can switch that row to use "minimum" height mode and it will be excluded from the calculations for "balanced" row height. Note that in the case of the Overview it will mainly result in the top row shrinking, as it becomes the only "balanced" row. Ultimately, I'm not sure if there's much we can do here, I don't consider the current behaviour "wrong" for the common case. We also don't want to limit the height of certain faces as that leads to tricky issues where individual parts need to become scrollable rather than just the page.
Created attachment 183851 [details] Screenshot with minimum height option selected The problem with the "minimum" height option is that the graphs become unreadable, as you can see from the screenshot.
It looks like the issue there is that the circular charts have implicit heights that are too small. That seems worth improving too. Meanwhile, it seems like there is indeed a way to accomplish what you want using the "minimum" sizing mode, it's just that it has other consequences that aren't ideal. I'm closing this, and will request new bug reports about the negative consequences of using the "minimum" sizing mode. Thanks!
I understand your position, but I respectfully disagree. The problem is, in my opinion, that the whole logic is flawed. The height of a row should not be defined by what other rows do, because that's entirely irrelevant. It should be defined by the content of that specific row. I don't see the point of having a page with regular rows, all of the same height: it does not improve readability nor accessibility (in fact I think it negatively impacts both, but I'd be happy to hear of any tests that have been done on this), it does not provide better usage of available space and it does not even provide a more aesthetically pleasing look. Regularity for regularity's sake is pointless. On the other hand, with regard to your suggestion, having a small representation with the "minimum height" setting can make a lot of sense in some scenarios, so I don't think this is really the issue that needs looking at (although there still *is* a problem with that).
> It should be defined by the content of that specific row Isn't that what "Minimum" does?