[pdm-devel] applied: [PATCH datacenter-manager v2] ui: pve tree: ellipsize overly long resource name to avoid overflow

[Thomas Lamprecht]

Am 30.01.25 um 12:07 schrieb Dominik Csapak:
> due to how the html/css layout is constructed, we have to manually take
> care of the (text)overflow here to have properly ellipsized text when the
> column gets too small.
> 
> To do this for all resources types, rework the markup generation here a
> bit, so that it's more consistent (e.g. same gap, align-items,etc).
> 
> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
> ---
> changes from v1:
> * reworked the whole column since this is relevant for all types of
>   resources not only lxc. Thanks for @Thomas to notice that!
>   (I did and tested with containers and forgot to do it for the rest,
>   oops...)
> 
>  ui/src/pve/tree.rs | 55 +++++++++++++++++++++++-----------------------
>  1 file changed, 28 insertions(+), 27 deletions(-)
> 
>

applied, thanks!

This is nicer, both code and UX wise than previously – compared to both, repo
status quo and v1.

Tangentially related:

One thing that got neither worse nor better is that it looks rather odd with
smaller view port sizes when there are no tags defined for any guest at all,
or at least for those currently visible. As there it looks like there's a
lot of space left unused while names get cut-off early (now at least they
are ellipsized, so looks _slightly_ less broken).

This is one of the drawbacks when not having borders for columns, but I'd
not jump to introduce such visible borders. One option might be to show the
headers, which could then allow us to expose changing the width of columns.
Another one might be using less space for tags, e.g., by rendering them
without text, not really ideal though (albeit not _that_ worse than now when
there's more than a low count of tags). Switching to another layout on
smaller resolutions could be also an option, I see if I can come up with
some ideas here, maybe you also got some, and we can talk in person to
come up with something next week or so.

FYI: the sizes I test for evaluating how it looks like with smaller screens
is 1300 x 680 px, which I created a custom dev entry in firefox named "768p
with OS/Browser Padding" as that I got reported by an actual user in the
forum and found as good lower minimum for where no element/functionality
of the UI should be broken or completely inaccessible. While that's certainly
not the resolution we should mainly optimize for, it can highlight some pain
points. 900p (1440 x 900 px) would be IMO better suited for a minimum
resolution where one can relatively comfortably use the UI and see (most)
core information without having to (vertically) scroll/reisze all too much.
Here even with 1080p (1920 x 1080 px) quite a few guests have their name cut
off, and that resolution really should show info like the VM name