[pve-devel] [PATCH] pending grid demo

[Alexandre DERUMIER]

>>- alignment of icons is not optimal? 
ok
>>- grid header is no longer needed 
ok
>>- second column should expand to full with 
ok
>>- edit uses current values, but should use pending values? 

mmm,maybe, but I'm not sure about this

>>- we need a 'Revert' button.
do we have already an api for "-delete pendingvalue" ?

>>- edit deleted value should be possible, 
 If we edit the current value, it should not be a problem ?
 I really to test this to see what is the best way.

>>and re-enabling the config? 
 Revert button  ?

> They also other things to fix, 

>>I think it is perfectly valid to edit pending changes. I think qemu-server 
>>patches 
>>can handle that without problems? 

Yes, I have begin to check this, should work without any problem with some qemu-server patches


>>Why don't we simply compute the correct value for next nic number, considering 
>>pending and deleted nics? 
Yes, you are right!


----- Mail original -----
De: "dietmar" <dietmar at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mercredi 17 Décembre 2014 12:10:26
Objet: Re: [pve-devel] [PATCH] pending grid demo

Some Notes after tesing: 

- alignment of icons is not optimal? 

- grid header is no longer needed 

- second column should expand to full with 

- edit uses current values, but should use pending values? 

- we need a 'Revert' button 

- edit deleted value should be possible, and re-enabling the config? 

> They also other things to fix, 
> 
> 1) 
> If a pending device exist,but no current device, (a new device) 
> 
> we should disable edit button. 
> (and maybe add a button to remove pending device) 

I think it is perfectly valid to edit pending changes. I think qemu-server 
patches 
can handle that without problems? 

> 2) for nic add (in gui), currently we auto find the next nic number from 
> config. 
> That mean than we trying to add multiple nic, the pending nic is always 
> replaced by the new one. 
> Maybe can we add a id field in form, same than disks. 

Why don't we simply compute the correct value for next nic number, considering 
pending and deleted nics?