From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 6400E1FF146 for ; Tue, 12 May 2026 09:13:14 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 838975F6B; Tue, 12 May 2026 09:13:12 +0200 (CEST) Message-ID: <9b13ad22-2e25-43ec-aebf-7a9cdd3a3b76@proxmox.com> Date: Tue, 12 May 2026 09:12:29 +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: Thomas Lamprecht , pve-devel@lists.proxmox.com References: <20260508134110.4001168-1-d.csapak@proxmox.com> <20260508134110.4001168-4-d.csapak@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1778569845843 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.050 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: DOPZO3RY5FRRFAWTHLCPWR2PJJTYPZPO X-Message-ID-Hash: DOPZO3RY5FRRFAWTHLCPWR2PJJTYPZPO X-MailFrom: d.csapak@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: Thanks for the feedback! On 5/12/26 4:04 AM, Thomas Lamprecht wrote: > 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. ah ok, my motivation was actually a different one, I wanted to make the various options of the nics and disks more visible (especially if there is a pending change) in different columns. So the button placement was not my primary reason, but I see what you mean. > > 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. Sure, I'll move the buttons the respective grids, should not be a big of a change (I hope ;) ). Another way could be to introduce an action column with the specific actions (either separate or as a menu) I think it could be even better, but I'd have to try it first. What do you think? We'd still have to keep the tbars for 'Add' at least. > > 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. sure, main reason was that the columns wouldn't always fit and either some columns would be empty for most of the rows, or we'd have to give some columns a double meaning I'll either include them in the grids (tpm and efi could work), scsi controller would be borderline IMO, or I'll include the rationale in the next version > > 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?). > > > I'm not exactly sure what you mean here? splitting the 'general' in two columns? the nic/disk grid are very wide with their columns already so showing either of them next to another grid is probably not good space wise.