Re: [PATCH manager v2 3/3] ui: qemu hardware view: split out disks and nics into grids

[Dominik Csapak <d.csapak@proxmox.com>]

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.