From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] ui: tape/BackupOverview: add 'restore partial' button
Date: Wed, 12 May 2021 08:44:02 +0200 [thread overview]
Message-ID: <4dc3a2eb-496f-8c74-d2f6-90d027047e52@proxmox.com> (raw)
In-Reply-To: <832918dd-13b3-cd87-e0f5-50b8e97ae97d@proxmox.com>
On 12.05.21 08:22, Dominik Csapak wrote:
> On 5/11/21 18:17, Thomas Lamprecht wrote:
>> On 11.05.21 14:42, Dominik Csapak wrote:
>>> this opens the restore window, but with a snapshot selector, so that
>>> the user can select the snapshots to restore
>>>
>>> includes a textfield for basic filtering
>>
>>
>> why isn't that handled directly in the restore window, without extra buttons?
>> Could possibly be a radio group there.
>
> yes you're right, that'll much better, though i would not do a radio button, but maybe only a checkbox '[] Select snapshots' which
> enables the selection grid?
>
> we could then open that window with a preselected(and filtered?) list when the user clicks on the 'restore single snapshot' button?
>
> does that make sense?
yes, can make sense - would be related to the backup-job edit window in PVE.
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.
>>
>> I really want to avoid many buttons in places like top-bars, makes it crowded
>> and confusing..
>>
>> Also, why doesn't this uses action buttons for those things like the content
>> tree? IMO we should try to be consistent with UX, cross-product this may be
>> hard and lots of work, but I do not see any excuse for intra-product consistency
>> (especially on rather simple UIs like PBS, compared to PVE).
>
> mhmm sounds good, i'd do an action column where each media set and
> snapshot gets a restore button, and for single snapshots i preselect
> like i mentioned above.. does that make sense?
>
yeah, if the others are still shown for the single snapshot I'd try to scroll
it in view or order it first though, so its immediately visible. We could even
order selected generally first by default, just an idea though...
> (we could probably do a restore button on every level in the tree,
> and preselect accordingly, though i am unsure if that does not
> get too confusing and if its even helpful...)
>
prev parent reply other threads:[~2021-05-12 6:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 12:42 Dominik Csapak
2021-05-11 16:17 ` Thomas Lamprecht
2021-05-12 6:22 ` Dominik Csapak
2021-05-12 6:44 ` Thomas Lamprecht [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=4dc3a2eb-496f-8c74-d2f6-90d027047e52@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pbs-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