public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Maximiliano Sandoval <m.sandoval@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH installer] tui: Add a cancel button to Advanced bootdisk options
Date: Wed, 21 Jun 2023 13:21:39 +0200	[thread overview]
Message-ID: <27e4a1ba-ba66-c7d0-4237-3aebefa78bcd@proxmox.com> (raw)
In-Reply-To: <3bb5c697-cad2-e9d6-0bd1-d043eb28a57d@proxmox.com>

> meh, this focuses first, before the Ok button, which is just makes the existing
> non-ideal UX

They way I see it, changing the existing settings for a disk is quite a high-commitment action. In such cases I would generally focus by default the button associated to the negative action, so yes it will require an extra TAB to get to the <Ok> button but I think it makes sense considering the consequences of the action.

Note that from a UX perspective the user cannot tell that the dialog starts with the current values (since the dialog is obscuring the previous values) and that pressing <Ok> will have no consequences if no field has been changed, and in the case they have changed the values they have no way to go back to the previous values if they have forgotten them. Or at least that was my experience.

> As with a cancel we really need to ensure that no callback has already changed
> data, not sure for the TUI, but the GTK UI would need quite some extra handling
> here

At the moment closing the advanced options in the GUI (it has its x button visible) will just close the dialog, just as this patch. The only line that changes something before the uses closes or activates the "Ok" button are

```
     $fstypecb->signal_connect (changed => sub {
	my $new_filesys = $fstypecb->get_active_text();
	Proxmox::Install::Config::set_filesys($new_filesys);
	&$switch_view();
     });
```
I would argue that the config changes should only apply after the user confirms the changes by activating the "Ok" button. As far as I understand the TUI installer at the moment won't change anything, e.g. via some callback, until the user presses <Ok> so adding a <Cancel> button that just closes the dialog won't do any bad.

On 6/21/23 12:40, Thomas Lamprecht wrote:
> Am 21/06/2023 um 11:16 schrieb Maximiliano Sandoval:
>> This matches the GUI installer which counts with a close (x) button.
>>
>> Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
>> ---
>>   proxmox-tui-installer/src/views/bootdisk.rs | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/proxmox-tui-installer/src/views/bootdisk.rs b/proxmox-tui-installer/src/views/bootdisk.rs
>> index 3fdbe5b..eaf343d 100644
>> --- a/proxmox-tui-installer/src/views/bootdisk.rs
>> +++ b/proxmox-tui-installer/src/views/bootdisk.rs
>> @@ -456,6 +456,7 @@ fn advanced_options_view(disks: &[Disk], options: Rc<RefCell<BootdiskOptions>>)
>>           &(*options).borrow(),
>>       ))
>>       .title("Advanced bootdisk options")
>> +    .dismiss_button("Cancel")
> meh, this focuses first, before the Ok button, which is just makes the existing
> non-ideal UX w.r.t. focus priority of buttons worse, so for now I rather have no
> such button - user can simply press OK, which is also a bit easier to have a
> clear understanding that the entered values are actually the ones then used.
> As with a cancel we really need to ensure that no callback has already changed
> data, not sure for the TUI, but the GTK UI would need quite some extra handling
> here.
>
>>       .button("Ok", {
>>           let options_ref = options.clone();
>>           move |siv| {




      reply	other threads:[~2023-06-21 11:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-21  9:16 Maximiliano Sandoval
2023-06-21 10:32 ` Christoph Heiss
2023-06-21 10:40 ` Thomas Lamprecht
2023-06-21 11:21   ` Maximiliano Sandoval [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=27e4a1ba-ba66-c7d0-4237-3aebefa78bcd@proxmox.com \
    --to=m.sandoval@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal