Testing the improved account wizard the "Generating new key pair..." takes too long In my opinion to block account setup. I think this might lead users to "ah cancel this" that takes too long. It took several minutes on my system.
I think it would be better to start the keygeneration job in the background and then send a DesktopNotification / Set it up as the key for the identity once that job is finished.

For usability I also think it would be better to include knewpasswordwidget in the Account Wizard itself instead of having pinentry pop up. I'll ask my collegues if they are concerend that this weakens security. I don't think so myself and the quality indicator of knewpasswordwidget is much better then pinentrys.

Hmm, the async generation is a little problematic. If the account wizard finishes all the other tasks before the keys are generated, it will still have to "stick around" until the keys are generated, so we are not really solving any problems. Even if we hide the window and just keep the process running in the background or something like that, the subsequent update of the Identity (to assign the newly generated key pair to the Identity) could clash with a changes that the user would be doing in the meanwhile (configuring signature in the identity edit dialog for example).

I think that if we just show some additional information (This may take several minutes blahblahblah) and maybe disable all buttons (Back/Next/Cancel), then the user will wait (won't have any other option :-)) - I don't think that usability-wise that is a big issue.

I like the idea with using KNewPwdWidget, Pinentry's ugly and does not integrate well (due to being a different process).

Is there some documentation on how to pass the password to the GnupgKeyParms XML instead of %ask-passphrase? Is there some documentation on the GnupgKeyParams XML format in general?

I've talked to Werner Koch and Bernhard Reiter.
They agree that we should query the passphase directly in this dialog (this will also mean key generation on the "Next" step).
They also both agreed that it should be ok, no additional click required, for the user to leave the passphrase empty.

The documentation for the key params is here:
https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html

For no password we need to add no-protection.

Regarding the background. I really would like to have it in the background. Can't we somehow register with DBus that we claim the identity configuration until our key generation is done to avoid configuration conflicts?

In T3130#57159, @aheinecke wrote:

I've talked to Werner Koch and Bernhard Reiter.
They agree that we should query the passphase directly in this dialog (this will also mean key generation on the "Next" step).
They also both agreed that it should be ok, no additional click required, for the user to leave the passphrase empty.

So the workflow would be:

Page 1: fill name and email, "Next" goes to page 2a
Page 2a: select existing key, "Next" goes to page 3, or select "Generate key", the "Next" goes to page 2b
Page 2b: fill passphrase, "Next" goes to page 2c
Page 2c: starts key generation in the background, continues to page 3
Page 3: starts the account setup, once done continues to page 4
Page 4: "Done"

Regarding the background. I really would like to have it in the background. Can't we somehow register with DBus that we claim the identity configuration until our key generation is done to avoid configuration conflicts?

Right now there is no such thing and I am not sure if it's worth the effort.

! In T3130#57169, @dvratil wrote:
Page 2a: select existing key, "Next" goes to page 3, or select "Generate key", the "Next" goes to page 2b
Page 2b: fill passphrase, "Next" goes to page 2c
Page 2c: starts key generation in the background, continues to page 3

Why is page 2c needed? I would have thought that Next on Page 2b would start the keygen.

Page 3: starts the account setup, once done continues to page 4
Page 4: "Done"

Cool :-)

Regarding the background. I really would like to have it in the background. Can't we somehow register with DBus that we claim the identity configuration until our key generation is done to avoid configuration conflicts?

Right now there is no such thing and I am not sure if it's worth the effort.

Ok. I thought to use the "This Config widget is opened in another Application" Mechanism of KCM's but yes I agree that it is not worth the effort. When our Key Generation Job returns it should just put the Key into the Identity configuration.