From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 96B0D1FF09B for ; Mon, 31 Aug 2026 14:18:08 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 4C02A2129E; Mon, 31 Aug 2026 14:18:08 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 Date: Mon, 31 Aug 2026 14:18:04 +0200 Message-Id: Subject: Re: [RFC PATCH datacenter-manager 2/2] ui: pve: load and use tag style overrides for resource tree From: "Lukas Wagner" To: "Dominik Csapak" , Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20260417141237.2004866-1-d.csapak@proxmox.com> <20260417141237.2004866-2-d.csapak@proxmox.com> In-Reply-To: <20260417141237.2004866-2-d.csapak@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788178671169 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.406 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: RSZZ47TE7VRQWASHS4JJBTIJBRDBOE4U X-Message-ID-Hash: RSZZ47TE7VRQWASHS4JJBTIJBRDBOE4U X-MailFrom: l.wagner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri Apr 17, 2026 at 4:10 PM CEST, Dominik Csapak wrote: > This loads the tag style overrides (currently only the color), from > /cluster/options once per remote when the remotes panel is opened, > and uses the color-map to change the appearance of the tags. > > Since the /cluster/options return value is just a `Value` currently, > introduce our own `TagStyle` and `DataCenterOptions` struct for parsing. > (This can be dropped when we update the return schema and types in > pve-manager and redo the return type in the pdm api) > > These will be converted into a `TagStyleOverride` struct that contains > the necessary infos and interfaces and can be cloned cheaply (as it uses > an Rc for the internal HashMap) so that we can easily move this around > in the code, e.g. into closures and callbacks. > > The only downside to this is, that the global tree (e.g. in the search > bar or a view) does not have these overrides and the tags can be > different. I think having a consistent style for tags would be quite important; to me, the style really is part of the 'identity' of the tag. In my opinion, either the entire PDM UI should properly respects the overrides that were configured in PVE, or not at all. Having two visual styles for the same tag is really not great, I think. That raises the overall question about tag 'identity'. Should PDM consider two tags with the same name (e.g. 'debian') from two remotes as the same? I would argue strongly argue in favor of that, and I'd also say that they should have the same style then. So, as a conclusion, I believe that tag style overrides should not be per-remote, but 'global' to PDM, applying to all remotes. To make this nicer for users, we could - allow importing existing overrides from PVE remotes (with the option to decide what happens if any imported style would override an existing definition) - allow applying configured overrides to remotes What do you think? > > Signed-off-by: Dominik Csapak > --- > Not sure if we want to use the per remote color/style overrides in PDM > at all, so I only included the color for now and sent as RFC. If we want > to include the style, sorting, etc. it should be easy to include. > > If we want this, I'd also go and fix the return types in pve-manager, > and update pve-api-types of course. Until then we could leave this in as > a stopgap. > Btw, this patch does not apply any more. Thanks!