With the code:
qCDebug(KLEOPATRA_LOG) << "Startup timing:" << timer.elapsed() << "ms elapsed: Service created"; AboutData aboutData; KAboutData::setApplicationData(aboutData); /* This is more expensive as it sounds as it might run a verification * on a signed Version file and initializes the whole GpgME::Engine. */ qCDebug(KLEOPATRA_LOG) << "Startup timing:" << timer.elapsed() << "ms elapsed: About data created";
I see:
[13096] org.kde.pim.kleopatra: Startup timing: 284 ms elapsed: Service created
[13096] org.kde.pim.libkleo: No signed VERSION file found.
[13096] org.kde.pim.libkleo: Parsed 2.2.41 as: 2 . 2 . 41 .
[13096] org.kde.pim.libkleo: Running gpgconf --show-versions ...
[13096] org.kde.pim.libkleo: Running gpgconf --show-versions timed out after 1 second.
[13096] QProcess: Destroyed while process ("C:\\Gpg4win\\bin\\..\\..\\GnuPG\\bin\\gpgconf.exe") is still running.
[13096] org.kde.pim.kleopatra: Startup timing: 1815 ms elapsed: About data createdSo what we see here is that gpgconf --show-versions takes more then a second and is even timed out. Afaik this is because it in turn calls all the processes which then do their initialization. Kleopatra caches this later but this is the first call.
On the Kleopatra side I think the solution will be to put the very important parts of KAboutData like Application Name and Organization which is used for config files and just put "Loading..." in the information of the branding texts. I guess they will never be opened before they are checked. Then we can put that into a background thread. As in the case of a signed version file the about data init would also do a gpgv call with a version validation. The timing shown above is without a signed VERSION file.
On the gpgconf side. I don't really know, its kind of a design issue that gpgconf starts each process to query information about the process so that all gpgconf calls take a while. We should try to delay this as long as possible and show UI before this.
This is a bit related to T6331 where a problem is that the KUniqueService is initialized too late on Windows to avoid parallel calls.
