- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 2 2022
The original issues have been addressed. Moreover, the actions are now available as buttons additionally to being available as context menu items.
Aug 1 2022
The OpenPGP-related changes mentioned in T5832#161063 have been implemented.
I think this was mostly covered with T5362: Kleopatra: Add warning in compliance mode if gnupg version is not compliant and T5653: de-vs and GnuPG 2.3.3 error.
Jul 29 2022
As discussed with Andre we streamline certificate generation as follows:
- We remove the "Choose Type of Key Pair" dialog.
- We replace the "New Key Pair" entry in the main menu with "New OpenPGP Key Pair" and "New S/MIME Certification Request".
- For OpenPGP, we replace the result dialog with the "Next Steps" buttons with a simple success message box.
- For S/MIME, we immediately show a Save File dialog instead of the result dialog.
Jul 28 2022
The table is now (more) accessible.
Also the size of the dialog changes abruptly once you select something.
Please try running Kleopatra with the "WindowsXP" or the "WindowsVista" style. The default "Windows" style is more like Windows 95 (https://doc.qt.io/qt-5/qstyle.html#details).
Jul 27 2022
Please give this a try on Windows.
This is related to T5950: Allow viewing expired certificates more easily where a user was wondering why some key wasn't offered as encryption key. It turned out that the encryption subkey was expired.
When the protocol is already choosen then the wizard is still opened and not the dialog. E.g. if the key is created from the welcomewidget's "New Key Pair" button. Or if S/MIME Certificate creation is disabled completely.
Now the buttons react to Enter/Return. But for now only the tool buttons in the welcome widget do. This needs to be extended to all other tool buttons used by Kleopatra. -> T6110: Kleopatra: All buttons shall be activatable with the Enter/Return key
I very much doubt that the buttons ever reacted on Enter. Those buttons are and always were QToolButtons. QToolButton doesn't reimplement keyPressEvent and QAbstractButton::keyPressEvent explicitly ignores Enter and Return. I think you are confusing this with the old "Choose Protocol" page of the wizard which used QCommandLinkButtons which indeed to react on Enter.
I'm using QFocusFrame for the visual indication. Qt uses QFocusFrame only with the MacStyle and there it probably looks much better. Breeze also uses it (inspired by the MacStyle).
Please add a subtask for the other problems in the welcome widget or add the information to the corresponding existing subtask (if there is one). This task here really only serves as Klammer-Ticket for the actual work items.
I know that the black frame looks bad. (It looks a bit better with Breeze.) The problem is that accessibility requires a visual indication of the keyboard input focus (see second recommendation for issue [3] in the report).
The table is now (more) accessible. The second issue doesn't apply anymore because of T6108: Kleopatra: Information on storage location of OpenPGP key should be per subkey.
Jul 26 2022
- Tables need to work with TAB focus and then arrow button navigation
Issues:
- Fingerprint is inaccessible (finding [3] in the Prüfbericht Barrierefreiheit GnuPG Kleopatra 3.1.20.3)
- "Certify with" label not associated with combo box
- Collapsible "Advanced" section is not accessible (announced as "check box")
- UI elements in "Advanced" section can receive focus, even if section is collapsed (finding [12] in the Prüfbericht Barrierefreiheit GnuPG Kleopatra 3.1.20.3)
- "Tags" label not associated with input field
- Pressing Esc cancels dialog even if explanation tooltip is shown
- "Domain" input field has no label (finding [4] in the Prüfbericht Barrierefreiheit GnuPG Kleopatra 3.1.20.3)
- No accessible feedback when checking/unchecking user ID