From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>, pdm-devel@lists.proxmox.com
Subject: Re: [PATCH datacenter-manager 0/4] add resource gauge panels to dashboard/views
Date: Wed, 25 Mar 2026 12:48:37 +0100 [thread overview]
Message-ID: <161f8c2c-0d0d-4c1d-aead-ecaf33a9822e@proxmox.com> (raw)
In-Reply-To: <DHAXUGV76A05.ESJE6TCAKQES@proxmox.com>
Am 24.03.26 um 11:25 schrieb Lukas Wagner:
> On Mon Mar 23, 2026 at 12:03 PM CET, Dominik Csapak wrote:
>> This uses the new pie charts[0] to add gauge panels for resources to
>> the dashboards/views. Either combined cpu/memory/storage or
>> indidivually, for pve/pbs or combined counts.
>>
>> for this we have to sum the data up in the backend.
>>
>> I also added these to the default dashboard (since it's data from an api
>> call we already query) but put that in a separate patch so we can easily
>> decide to not apply that. (not sure if we want to change the default
>> dashboard)
>>
>> Note that the pwt patches [0] have to be applied and the package
>> has to be bumped first.
>>
>> 0: https://lore.proxmox.com/yew-devel/20260320160816.4113364-1-d.csapak@proxmox.com/
>>
>> Dominik Csapak (4):
>> api: return global cpu/memory/storage statistics
>> ui: css: use mask for svg icons
>> ui: dashboard: add new gauge panels widget type
>> ui: dashboard: add resource gauges to default dashboard
>>
>> lib/pdm-api-types/src/lib.rs | 2 +-
>> lib/pdm-api-types/src/resource.rs | 27 ++++++
>> lib/pdm-api-types/src/views.rs | 15 +++
>> server/src/api/resources.rs | 65 ++++++++++---
>> ui/css/pdm.scss | 35 +++----
>> ui/src/dashboard/gauge_panel.rs | 156 ++++++++++++++++++++++++++++++
>> ui/src/dashboard/mod.rs | 3 +
>> ui/src/dashboard/view.rs | 19 +++-
>> ui/src/dashboard/view/row_view.rs | 43 +++++++-
>> 9 files changed, 331 insertions(+), 34 deletions(-)
>> create mode 100644 ui/src/dashboard/gauge_panel.rs
>
> Thanks for these patches!
>
> Some thoughts, some of which we already discussed off-list:
>
> - I'd suggest a wider opening angle for the gauges, so that the gauges
> are a bit more compact and look less like a horse shoe
> To me, 75/285 looked quite good, but this is of course highly
> subjective, so no hard feelings
Didn't bother me that much when initially looking at it, but you might have
a point, especially w.r.t. how the text below the gauge fits visually.
As of now the angle of the gauge edges seem slightly "pointy" w.r.t.
horizontal line the text gives off (for the lack of a better description).
FWIW, Grafana defaults to then moving the value inside a bit lower, so that
it basically lines up with the bottom edges of the graph, no hard feelings
here, just mentioning it as comparison.
> - For the percent-label inside the gauge, I think 0 (zero) significant
> digits are okay, for such a 'global' infrastructure gauge two
> significant digits are hardly useful, I think
one might be OK, at least for <1 and >99 %, and then we might just always
add it. but, tbh, using zero for now might be fine too. For large setups
a single decimal point in percentage might be still some sizeable real
absolute amount though.
A space between value and unit might be nice.
>
> - We probably should use full product names (Proxmox VE, Proxmox
> Backup Server) in the card headers, instead of just "PVE" and "PBS".
> The overall text length could become quite long though, so maybe we
> need some other approach for the card title.
+1, but no good solution from top of my head, might be easiest to live
with the long texts.
Additionally:
For widgets multiple gauges placing the icon+label inside or below the
gauge might look a bit better. At the top it looks slightly out of place
as is. Or written differently: there's now some info on top, in the mid
and below, so visually many differnet locations a users eye has to wander,
feels "unruhig".
Small nit: For PVE CPU Usage it's not immediate clear how the load values
and the allocated relay to each other.
Font is handled by the SVG, how is the font family and sizing chosen there?
does the size always scales nicely?
I'll try to reply on the yew-devel series too, but from a quick check I did
not found any note w.r.t. this.
next prev parent reply other threads:[~2026-03-25 11:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 11:03 Dominik Csapak
2026-03-23 11:03 ` [PATCH datacenter-manager 1/4] api: return global cpu/memory/storage statistics Dominik Csapak
2026-03-25 16:49 ` Thomas Lamprecht
2026-03-26 7:59 ` Dominik Csapak
2026-03-23 11:03 ` [PATCH datacenter-manager 2/4] ui: css: use mask for svg icons Dominik Csapak
2026-03-23 11:03 ` [PATCH datacenter-manager 3/4] ui: dashboard: add new gauge panels widget type Dominik Csapak
2026-03-23 11:03 ` [PATCH datacenter-manager 4/4] ui: dashboard: add resource gauges to default dashboard Dominik Csapak
2026-03-24 10:25 ` [PATCH datacenter-manager 0/4] add resource gauge panels to dashboard/views Lukas Wagner
2026-03-25 11:48 ` Thomas Lamprecht [this message]
2026-03-25 13:12 ` Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=161f8c2c-0d0d-4c1d-aead-ecaf33a9822e@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.