From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Nicolas Frey <n.frey@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-manager v3 1/1] ui: fix #6209: create snapshots and backups from context menu
Date: Tue, 7 Oct 2025 12:49:52 +0200 [thread overview]
Message-ID: <b2dc1481-500e-456c-a329-2966326560e9@proxmox.com> (raw)
In-Reply-To: <fea48956-d0cd-4436-b666-e31986283d0d@proxmox.com>
Am 07.10.25 um 12:34 schrieb Nicolas Frey:
> I used some variations of added network throttle using chrome dev
> tools and traffic control and noticed that the disabling of the button
> is starting to get really noticable in the 1-1.5 second range (if you
> don't have sniper level mouse accuracy). Anything below that is
> negotiable, but if the request stalls even a bit above that range it
> could become an annoyance (e.g. being just about too early and having
> to click a second time or simply the long wait). Though similarly, you
> still have to wait for the window to appear if you clicked it in the
> new version, and there may also be an error if snapshots aren't
> supported on the guest.
Thanks for checking so closely and reporting back!
> As a note, the original implementation (v1/v2) matches the behaviour
> found in the Snapshots tab, which has the button disabled until
> querying snapshot features is complete. This also shows that the
> `current guest does not support taking new snapshots` until fully
> loaded. IMO parity between them is essential, as to not have two
> different approaches which might confuse users.
>
> I cannot tell which approach is better here, but it might be a sign
> that Shannon had also suggested the other way...
Yeah, that, and this being basically pre-existing behavior in the
Snapshots tab, like you mentioned, is probably enough weight to tip the
scale towards your original approach.
Thanks for trying this out though, sometimes some experimentation is
needed, and even though it's only a small UX thing, these things tend to
get copied and thus leak often quite fast in other parts of the UI or
even UIs for our other projects, so it can be worth to look more
closely once in a while here.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-10-07 10:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 13:33 [pve-devel] [PATCH pve-manager v3 0/1] " Nicolas Frey
2025-10-06 13:33 ` [pve-devel] [PATCH pve-manager v3 1/1] " Nicolas Frey
2025-10-07 8:42 ` Shannon Sterz
2025-10-07 9:13 ` Shannon Sterz
2025-10-07 9:14 ` Nicolas Frey
2025-10-07 9:16 ` Thomas Lamprecht
2025-10-07 10:35 ` Nicolas Frey
2025-10-07 10:49 ` Thomas Lamprecht [this message]
2025-10-07 12:14 ` [pve-devel] [PATCH pve-manager v3 0/1] " Nicolas Frey
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=b2dc1481-500e-456c-a329-2966326560e9@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=n.frey@proxmox.com \
--cc=pve-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox