Add more UI feedback to print, print transcript dialogs

[rocodes]

Status

Ready for review

Description

Fixes #2125

Test Plan

• CI passes
• Visual review
• Hover state (light blue) on print dialog Continue and Cancel buttons
• Spinner animation on Continue button after print preflight (when dialog says "Ready to print ___") once user clicks it. Best tested by printing a file that requires PDF conversion, so the dialog is open for a while.

The easiest way to test may be to give sd-app network access, install all required dependencies, check out this branch in sd-app, and run ./run.sh --sdc-home=/home/user/.securedrop_client with the venv activated, although you can also build from the tip of this branch and install the deb in sd-app.

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on main and confirmed that the migration is self-contained and applies cleanly
• I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[rocodes]

(Just putting it in draft for a min because I'm going to tack on some hover css for the "Cancel" button too so that it looks like the Export wizard.)

[deeplow]

although you can also build from the tip of this branch and install the deb in sd-app.

I went this route.

I can confirm the correct behavior and pretty much good to do.

One idea is to also have the "continue" text to show up. I made this work by removing the setText("") from the animate function, but then the loading icon showed up on the left. Not perfect. I experimented a bit with alignment to get it to show on the right without much success (but the iteration time was quite slow so I didn't try a lot).

But in any case, it also looks / works fine as is and is much better than the apparent 'hanging' from before.

Ready to merge, if showing the text is not something worth considering.

[rocodes]

Thanks - I think since they can't actually press "Continue" again (button is disabled) and since the spinner is in the same place as it is for the ExportWizard, if you think it's an improvement over the current, I'd lean towards leaving it as is in this release.

Two possibilities for changing this:

• I'm working on Disable "Print" when file format is not conducive to printing #918 and think we should do a light printer dialog refactor before that (Deprecate PrintTranscriptDialog and just use PrintDialog #2132) ; if we decide this UI change is needed, let's do it as part of that refactor so we're not maintaining the code in 2 sets of dialogs anymore?
• Ultimately we should move away from using modal dialogs like this and changing the button state, and move towards a wizard style, so we don't have to enable and disable text and click handlers and overload the same button, so we could wait and revisit all the button UI in our printer overhaul.

[deeplow]

Thanks - I think since they can't actually press "Continue" again (button is disabled) and since the spinner is in the same place as it is for the ExportWizard, if you think it's an improvement over the current, I'd lean towards leaving it as is in this release.

Sounds good leaving it as is.

(#2132) ; if we decide this UI change is needed, let's do it as part of that refactor so we're not maintaining the code in 2 sets of dialogs anymore?

💯

[legoktm]

Per deeplow