From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D6FD8706E2 for ; Fri, 14 May 2021 08:37:25 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C7DE8129D9 for ; Fri, 14 May 2021 08:37:25 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 6FB70129C9 for ; Fri, 14 May 2021 08:37:24 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4191F42966 for ; Fri, 14 May 2021 08:37:24 +0200 (CEST) Message-ID: Date: Fri, 14 May 2021 08:37:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Dominik Csapak , Proxmox Backup Server development discussion References: <20210512114952.19599-1-d.csapak@proxmox.com> <130787f9-a4cd-def7-b04b-239c620db67b@proxmox.com> From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.006 Adjusted score from AWL reputation of From: address CTE_8BIT_MISMATCH 0.001 Header says 7bits but body disagrees KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup v2] ui: tape/BackupOverview: unify and improve tape restore window X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 06:37:25 -0000 On 14.05.21 08:29, Dominik Csapak wrote: > On 5/12/21 21:34, Thomas Lamprecht wrote: >> On 12.05.21 13:49, Dominik Csapak wrote: >>> adds a snapshot list to the restore window where the user can >>> select distinct snapshots to restore >>> >>> this also replaces the restore / restore single button by >>> inline actions for the media-set, backup groups and snapshots >>> >>> when clicking the action for a group/snapshot, the snapshotselector >>> gets activated and preselected/filtered so that it includes those >>> snapshots (can be overridden from the user) >>> >>> this change means that we now load the media set everytime we open >>> the window, since we want to have the list of snapshots. >>> (we could build that from the tree again, or hold it there somewhere as >>> list, but i do not think we gain much with that, and it simplifies the >>> datastore selection code a bit) >>> >>> Signed-off-by: Dominik Csapak >>> --- >>> changes from v1: >>> * fixed snapshot selection checkbox (was in wrong context, looup needs >>>    to happen on the referenceHolder) >>> * removed unnecessary 'node' variable in 'restore' function >>> * fixed 'media-set' text in window (was the text of the node we clicked on) >>> >> >> Recently it seem to me like we alternate between "place every new function and >> it's use in 42 separate patches" and "dump^W squash three-zillion changes into >> one" like a metronome, none of those is  ideal IMO. >> >> IOW, this really needs to be two patches, one for the content overview changes >> and the restore widow. > > ok will do > >> >> Also, from my last reply to the v1 thread: >> >>> IMO slightly better than radio-group/checkbox as it removes a UI control >>> element completely, so less choice/confusion, but without scarifying flexibility, >>> so IMO a good idea. >> >> Now you added the extra checkbox...  Why not just use the grid-header checkbox like >> PVE backup-job edit-window and tick it by default when restoring a whole set? >> >> As said, reduction by one knob without losing any flexibility - seems like a win >> win to me, or do I overlook something? >> >> With the list below the window's aspect ration feels wrong and the list a bit >> squished, I'd add a few 100s px to the window height to improve that. >> > > ok this was a misunderstanding then... > > yeah using the 'check all' checkbox makes sense, but then i am unsure > how to handle filtering. > > now only visible entries get restored, so if a user would (with the check all) filter, it would seem like still all are selected and > we generate wrong assumptions? > we *should* be able to uncheck the check all box though to reduce > confusion, and this seems to me the best way forward. > not sure this is a problem, in the search functionality for the PMG spam quaratine the not visible entries just get deselected, if the filter is cleared then nothing needs to be done, at all time the only things actually selected must be visible (out ov view due to long list naturally not counted) > the alternative is that we restore *all* selected entries, filtered or not, but this can be similarly confusing since things get restored that > weren't visible > I'm a bit confused here, I do not see the problem? Filtering deselects items which got filtered out, and the rest then falls in place. > in pve's 'mass *' windows we have a behaviour like the first suggestion, > but i just noticed, depending on which column gets filtered, the > 'check all' box sometimes stays checked and sometimes not... > > as for the height, if there are multiple datastores on the media-set > (idk if you tested with this), there is another grid for the > datastore mapping, with that the window is already quite tall > > maybe a multi-step 'wizard' would be better? that or move one grid to a side. > > let the user first select the basic choices (drive,user,etc.) > then a window with a full-size grid of the snapshots, and then > depending on what he selected, either a target datastore > or datastore mapping input? > > (or the snapshots first, and the rest of the info on the second panel?) >