From: "Shan Shaji" <s.shaji@proxmox.com>
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>,
"Dominik Csapak" <d.csapak@proxmox.com>,
"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve_flutter_frontend v3] feat: ui: add lock/unlock button in guests options page
Date: Thu, 18 Sep 2025 10:44:30 +0200 [thread overview]
Message-ID: <DCVSLAR7RIZ6.28ENKWP3ISOSY@proxmox.com> (raw)
In-Reply-To: <9c6bdbb6-b99b-47c7-97d0-38e4931838b6@proxmox.com>
Thanks @Thomas and @Dominik for the review, I will create another
patch that will align with the mobile web UI which will be a bottom
sheet with the explicit update or reset button.
Also, the changes will only reflect on the existing editable options.
On Wed Sep 17, 2025 at 10:41 AM CEST, Thomas Lamprecht wrote:
> Am 17.09.25 um 10:06 schrieb Dominik Csapak:
>>
>>
>> On 9/4/25 11:25 AM, Shan Shaji wrote:
>>> On the options page for VMs and CTs it was easy to change the
>>> configs by mistake. To avoid that, added a lock/unlock button
>>> on top of the screen. The toggle buttons will only be enabled
>>> if the button is clicked.
>>>
>>> Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
>>> Signed-off-by: Shan Shaji <s.shaji@proxmox.com>
>> I did not apply this, as we're currently evaluating a different approach
>> for the yew mobile ui. If that works out, i'd prefer to have both uis
>> the same (or at least similar) approaches here
>
> For the record: the idea is just using bottom sheets with an explicit
> "update" save button for each property, i.e. both, single value ones
> and more complex property strings.
>
> As we do not plan to very actively extend the Apps capabilities to cover
> the full option range for VMs/CTs that PVE allows and just keep the
> simple options we got now I'm not really sure if syncing app and mobile
> web is really something we have to do. That said, I have nothing against
> using a bottom sheet there too, it's a common approach and works well
> for most things, but I'm also fine with going a different route,
> especially if we do not expand the availability of options and HW to
> configure soon(ish) here anyway, we can still change this later should
> that happen.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-09-18 8:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 9:25 Shan Shaji
2025-09-17 8:06 ` Dominik Csapak
2025-09-17 8:41 ` Thomas Lamprecht
2025-09-18 8:44 ` Shan Shaji [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DCVSLAR7RIZ6.28ENKWP3ISOSY@proxmox.com \
--to=s.shaji@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.