As 2.3.7 was released on the 11th of July, see https://lists.gnupg.org/pipermail/gnupg-announce/2022q3/000474.html
I guess that this issue should be closed and some issues moved to one with 2.3.8.

Priorities went off this task for three years now. Is "Release Info" still the right tag?

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.

We have three styles enabled / installed, Windows the Windows 95 style. Windows Vista and fusion. Windows Vista is the default. On Windows 10 these look like the following. On windows 11 they look slightly different again but that is mostly due to window decorations.

The table is now (more) accessible.

Fixed with commits
rGeb675fbc4e4db52c3276bc0748b49df8a213fbc4
rG890e616593af5d1e0f2eb932768205ef90928e5e

The referenced bug should have been T6063

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).

Yes, I think that makes sense in the way that we want to provide the best user experience for our own users even if they communicate with communication partners which creates problematic keys.

In de-vs mode we could change the implict algorithm from SHA-1 to SHA-256. That should solve the problem.

For this dialog I think we need additional work. I have not yet tested it on Windows 11 but at least on Windows 10 with the default theme it looks much less like a native dialog and more like a "Windows XP" Dialog now. Please do not see this as nitpicking, I know it is hard to have something accessible and both pleasing to the eye but I think that this is something we should try to archive.

Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.

Here is the parser output:

$ python3 sd.py --type=pipe "D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)"
D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)
    Discretionary ACL: P(A;;GA;;;SY)(A;;GA;;;BA)(A;;0x12019b;;;AU)
        Flags: P: SE_DACL_PROTECTED (Blocks inheritance of parent's ACEs)

I think that the last argument of CreateNamedPipeA can limit the access to the named pipe.

Here is a patch to implement the functionality with --enable-win32-openssh-support.

Fixed in master.

I have over 75 PGP addresses:

Please give this a try on Windows.

With the Breeze style the (old) focus indicator looks like this:

@werner Could these two patches could be backported to 2.2? These changes give same level of performance increase in 2.2 as seen in 2.3.

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.

Backported for for 2.2.37

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.

This is about showing the corresponding about dialog text for the disable support option.

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

Sorry, I did not mean to imply that this was a regression, I only noticed this as I was tabbing through the welcome dialog and then wanted to test openpgp certificate creation by keyboard and was also irritated that it did not work as expected on the button.

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).

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.

In T5824#160925, @ikloecker wrote:

Because it doesn't look good, but it is required for full accessibility, I have considered adding a configuration option to enable/disable extended accessibility.

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).

Fix will go into 2.2.37 and 2.3.8.

I tried to reproduce this as we had similar problems in the past, but for me this works with full unicode characters.

The welcomewidget has some problems: