[FEATURE] Switch from YES/NO buttons to labelling the actions that would be taken

[jedahan]

Is your feature request related to a problem? Please describe.
The dialogue popups have caused confusion in the past (see #757 and #624 and #700) - it would be nice to have the buttons say what action they will take instead. As per #757, I am opening a pull request describing the solution before trying to implement it.

Describe the solution you'd like

On the write confirmation dialogue

• Change 'Yes' to 'Erase all contents of the drive and continue'
• Change 'No' to 'Keep the contents of the drive and cancel the write'

On the OS Customization Dialog

• Change 'Yes' to 'Apply OS Customisations and write'
• Change 'No' to 'Write without applying OS Customisations'
• Change 'Edit Settings' to 'Edit OS Customisations'
• Remove 'No, Clear Settings'

In OS Customization Settings

• Add 'Reset all settings to defaults' or 'Clear All OS Customization Settings' button to the left of the Save button

Describe alternatives you've considered
Considered showing what customisations would be applied in the confirmation box

Additional context

• Previous bugs - [BUG] Order of YES and NO buttons differs between popups, causing confusion. #757, Show options when opening image by file association #642, "No, clear settings" is too ambiguous #700
• Previous PRs - Swap no/yes placements #150

[tdewey-rpi]

This proposal would align closer with that I think should happen - however I've not previously explored it because it can only vary the vertical height of the dialog - there's no scope to make a wider window, due to constraints running on low-resolution displays.

Stacking the actions vertically, while it has precident in Raspberry Pi OS, has no equivalent reference inside Raspberry Pi Imager - where by convention actions have been kept as left-to-right, rather than top-to-bottom.

It is that convention that has prevented me considering such changes until we can re evaluate the UI. Otherwise we could wind up with a disjointed user experience that will go through potentially two paradigm shifts before arriving at a new stable point - rather than just transitioning directly to the new stable point.

[jedahan]

What are the lowest and highest (1x scale) resolutions we would like to support? I can make some mockups/screenshots to help move this forward.

[tdewey-rpi]

What are the lowest and highest (1x scale) resolutions we would like to support? I can make some mockups/screenshots to help move this forward.

Highest: Underdetermined. I see 8K monitors are shipping now, though I very much doubt anyone is driving those at 1x
Lowest: Specified in our main QML layout file, https://github.com/raspberrypi/rpi-imager/blob/4b6ee9bb4b1f29587db6145d82f4784d8863d036/src/main.qml#L17C1-L20C59

Note that English is also one of the most compact representations of text supported by rpi-imager. We have a range of translations, including those from non-ASCII character sets that may occupy significantly greater widths.