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 4AA731FF191 for ; Tue, 7 Oct 2025 12:35:23 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8B45B15C53; Tue, 7 Oct 2025 12:35:25 +0200 (CEST) Message-ID: Date: Tue, 7 Oct 2025 12:35:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion , Shannon Sterz References: <20251006133308.119141-1-n.frey@proxmox.com> <20251006133308.119141-2-n.frey@proxmox.com> <77926145-fad2-4ff4-8da4-97341a29d1b1@proxmox.com> From: Nicolas Frey Content-Language: en-US In-Reply-To: <77926145-fad2-4ff4-8da4-97341a29d1b1@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1759833292070 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.936 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH pve-manager v3 1/1] ui: fix #6209: create snapshots and backups from context menu X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Cc: pve-devel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 10/7/25 11:16 AM, Thomas Lamprecht wrote: > Am 07.10.25 um 10:42 schrieb Shannon Sterz: >> one small thought: have you explored whether querying the features of >> the guest when opening the context menu and graying out the snapshot >> option is viable? imo that would be a nicer user experience, but the >> overhead of querying the backend there might be too much. > > FWIW, Nicolas did that in v1/v2, but I wondered w.r.t. slow backend > or spotty and/or high-latency connection making this odd to use. > But I just found that my reply was not CC'ing the list, so I just > re-send it for the record: > https://lore.proxmox.com/pve-devel/9563cc43-f8ad-4b33-b8ea-a22d22b3405e@proxmox.com/ > > That said, given that you suggested the other way around for UX, it > might be indeed better to keep it that way, or at least actually try > how that way works with a slow backend (developer tools can simulate > slow network (the chromium based ones are a bit more powerful in that > regard IIRC), or alternatively use a traffic control (tc) netem qdisc > that adds latency [0] can be added on the PVE server. > Because as mentioned, it could be fine your previous way and the one > Shannon also would prefer, I rather wanted to avoid that we just take > our rather perfect fast and sub-milliseconds lab environments as sole > base for UX decisions. > > [0]: https://manpages.debian.org/trixie/iproute2/tc-netem.8.en.html > e.g. something like: tc qdisc add dev eth0 root netem delay 3000ms 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. 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... _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel