this works now:

@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory

But shouldn't we then rather rename the shortcut of Kleopatra to: GnuPG VS-Desktop - Kleopatra ? That would make it discoverable under both names.

Our sales team gets the support calls and they have to explain that really often.

werner I strongly disagree here. There is no need for this for our software on Windows and that is definitely not the Windows way, esp. with our current feature set. Do you really think a user wants to start "GnuPG VS-Desktop" to then have a selection between Okular, Outlook, and Kleopatra? That is not how this works at all. Definitely not High priority for us if you think Kleopatra is too hard to discover then we could add another start menu entry for Kleopatra called "GnuPG VS-Desktop" but a starter that only offers to switch between Okular and Kleopatra currently does _not_ have high priority, For windows this is solved with the windows registry, If you want to make Okular - GnuPG Edition your default PDF reader you can, similarly for Kleopatra and please also keep in mind that a user wants to "Encrypt" or "Decrypt" a file. And does not necessarily care about Kleopatra.

FWIW, we also need this for Windows. ppl often ask what to do after they installed VSD because they can't find a program. Thus a menu ala Kontact is the way to go. It would be linked directly from a GnUPG Desktop entry from Windows. We can even keep the old Kleopatra becuase it does not harm. Whether the "menu" is a container window or a detached windows can be decided by the user, like GIMP and other tools do this.

I suppose you have read https://docs.appimage.org/user-guide/run-appimages.html#integrating-appimages-into-the-desktop, even though I think those two helpers don't do what you want and, on top, they are Linux-specific.

While the DBus problem is interesting and I want to further investigate this, I think the real question or feature we need to have here is to attach multiple "UI Processes" to an AppImage environment. So that you can have an Okular, KMail and Kleopatra running in your VSD environment without going through the console.

I am pretty sure what I want to do here. There is no way around .desktop files if we want to have proper linux integration. Otherwise you cannot for example have okular gnupg in the "start with" menu. It is something like the Windows registry integration. Or make KMail with GnuPG Desktop your default Mail client etc.

It's a shell issue. With bash Kleopatra starts from the shell. Andre will debug further.

I used dbus-monitor to monitor the session bus. I'm seeing the following logged by dbus-monitor when starting kleopatra in the AppImage shell.

method call time=1690445994.197305 sender=:1.141 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method return time=1690445994.197348 sender=org.freedesktop.DBus -> destination=:1.141 serial=1 reply_serial=1
   string ":1.141"
signal time=1690445994.197368 sender=org.freedesktop.DBus -> destination=(null destination) serial=93 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.141"
   string ""
   string ":1.141"
signal time=1690445994.197394 sender=org.freedesktop.DBus -> destination=:1.141 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.141"
method call time=1690445994.197919 sender=:1.141 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameAcquired'"
method call time=1690445994.198591 sender=:1.141 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
   string "org.kde.kleopatra"
   uint32 0
signal time=1690445994.198656 sender=org.freedesktop.DBus -> destination=(null destination) serial=94 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.kde.kleopatra"
   string ""
   string ":1.141"
signal time=1690445994.198680 sender=org.freedesktop.DBus -> destination=:1.141 serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string "org.kde.kleopatra"
[...]

and when quitting Kleopatra I see

method call time=1690446001.636935 sender=:1.141 -> destination=org.freedesktop.DBus serial=21 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName
   string "org.kde.kleopatra"
signal time=1690446001.636978 sender=org.freedesktop.DBus -> destination=:1.141 serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string "org.kde.kleopatra"
signal time=1690446001.636991 sender=org.freedesktop.DBus -> destination=(null destination) serial=97 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "org.kde.kleopatra"
   string ":1.141"
   string ""

I have just started kleopatra in the shell. Moved it to the background (Ctrl+Z bg). Then started okular. Then opened certificate of signed PDF in kleopatra. Everything works. (Except "Show Signatures Panel" doesn't really work if the side panel is not visible, but that's a completely different issue.) I also tried first starting okular and then kleopatra in the same shell. This also worked.

Right, I had briefly uploaded a "GnuPG-Desktop" appimage but then realized that for the gnupg.org download site the "GnuPG-Foo" was actually the correct version. Werner and me discussed the future of that version and there will be some changes for future releases which I won't go in there. But functionally it is the same, only the VERSION file differs.

I cannot reproduce this. Neither with the official AppImage nor with my self-built AppImage. The error message suggests that some process is still registered with DBUS. Maybe a process left over from a previous run?

signing works, too

follow up of T6517

Meanwhile the AppImage (same binaries as the current Gpg4win version) can be found here among the binary releases: https://gnupg.org/download/index.html

Discussed with werner is for Wontfix as this is not really the AppImage way to do things. As you also seem to tend this way I slightly agree. I still would find it nice to have but If we have a real demand for that we can document or support people to do this.

Okay. It doesn't solve the problem that you want to run any application via the GnuPG VS-Desktop AppImage.

I think AppImageLauncher solves this already. And for discoverability there's AppImageHub (which the distribution-specific desktop installers may already support as source for applications).

Thanks for the analysis!

Hello, i did some debugging with my local sks keyserver version 1.1.6+ on Debian:

Just to clarify: Does this only happen with self-built AppImages? Or does this also happen with AppImages provided by gnupg.com/gnupg.org?

Just to clarify: Does this only happen with self-built AppImages? Or does this also happen with AppImages provided by gnupg.com/gnupg.org? (I haven't found AppImages to download on gnupg.org.)

Hello ...

I may report, that I've tested this behaviour with "kleopatra" with serveral keyservers.

I guess the problem is that the fix for T5741: dirmngr does not ask keyservers for fingerprints wasn't backported to 2.2.

But this is with the default keyserver keys.ubuntu.com it shows the fingerprint if I do a search --with-colons with 2.3 and the same keyserver (addressed via IP) on the same machine returns results on Windows and says No Fingerprints in the app image. This is what I found so strange here.

Looks like a duplicate of T5725: Kleopatra: Certificate lookup shows only one result even if there are 100s matches. Solution: Use a key server that returns fingerprints.

I can reproduce the problem. Under Windows it works, with my development setup with GnuPG 2.3 it works, but in the appimage I get the error that all keys were skipped.

We have everything ready for a GnuPG Desktop Appimage but we first need a business case to maintain it.