From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 4C5821FF146 for ; Tue, 12 May 2026 04:07:13 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9CB1526AF7; Tue, 12 May 2026 04:07:10 +0200 (CEST) Message-ID: Date: Tue, 12 May 2026 04:06:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH manager v2 3/3] ui: qemu hardware view: split out disks and nics into grids To: Dominik Csapak , pve-devel@lists.proxmox.com References: <20260508134110.4001168-1-d.csapak@proxmox.com> <20260508134110.4001168-4-d.csapak@proxmox.com> Content-Language: en-US, de-DE From: Thomas Lamprecht In-Reply-To: <20260508134110.4001168-4-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1778551484793 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.003 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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: CZ37JHGMWL763L3DUPY535V3LVIUDBS5 X-Message-ID-Hash: CZ37JHGMWL763L3DUPY535V3LVIUDBS5 X-MailFrom: t.lamprecht@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 VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 08/05/2026 15:39, Dominik Csapak wrote: > This is done to improve visibility of configuration of disks and nics. > Currently only the raw property string is shown in the UI, which leads > to bad UX when having many options configured and especially when having > pending changes in these situations because it's hard to parse visually. > > The disks and nics are shown below the main options, each as their own > grids with relevant columns. By default all columns that can be edited > in the gui are shown (with the exception of the bandwidth limits, since > they're not often used and blow up the number of columns). All other > options from the config are there but hidden by default. > > As a fallback, in case there are new options not yet in the ui, a 'Raw > Config' column was added, which contains the raw property string again > (but it's hidden by default). > > Some notes on the implementation: > > The stores for the new grids are populated on each load of the main > grid, and the we have one combined pending store that's just there to > save the parsed pending values. > > To keep the diff smaller, some helpers are introduced to forward some > methods to the main hardware grid. > > The selection change introduces some logic to keep the selection only > in one grid, so there can be no conflict on the selected values. Thanks for this, main question here: why not move the buttons too? I.e., the hardware view is rather crowded and that's a main reason for doing this originally, but a big part of the problem isn't really the amount of rows (for VMs with many disks and or NICs that naturally can become a problem too), but the edit buttons and their complex state/display changes depending on what is selected. In my (not so thought out!) vision I'd have added a tbar to each panel and reworked the buttons such that only the ones relevant for the elemens in there are shown, as else this is IMO going sidewards, if not even getting slightly worse in some aspects, as the element to edit and the edit/action button are even a "bigger" distance between them, so to say. Also, might be nice to have some explicit rationale for why things like TPM and EFI and maybe even SCSI controller are not part of the disks panel - not saying the must be, but they are at least hard disk related and thus IMO worth adding an explicit rationale, even if they are not normal hard disks and thus fall out a narrow/literal interpretation of the "Hard Disks" sub-panel. Layout wise I'm also not so sure if it wouldn't be better to split the vertical space more evenly (or give the general one a only som padding and flex the other two below?).