Re: w32: GPA use of libgpgme-glib
NIIBE Yutaka via Gnupg-devel <[email protected]> Thu, 21 May 2026 10:15:46 +0900
| Newsgroups | gmane.comp.encryption.gpg.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello, Werner Koch <[email protected]> wrote: > The actual reason why we have the glib variant is for Windows. On Windows, libgpgme-glib offers the IO backend which uses glib, so, it is more friendly to..., say, GTK applications. That's true. I think that libgpgme-glib was/is intended to include more higher layer things, like event loop integration (as GPGME for Qt did). However, in the current implementation, it only offers the IO backend (specifically for Windows), nothing more. AFAIK, it works exactly same as libgpgme native IO backend for Windows. The difference is using glib API or native Windows API. We don't have threading support and/or event loop integration in libgpgme-glib (yet). In the particular use cases in GPA, I don't think it make sense to keep using libgpgme-glib. In my opinion, use of libgpgme is enough. Well, for now, I don't pursue to put my change to GPA, until some Windows developer will kindly confirm about no libgpgme-glib is needed. And... I took a conservative and indirect way. I pushed a commit to GPGME: 2e02b9d0243d6c27562b01f18bf4976a816af6f6 ========================== m4: Deprecate AM_PATH_GPGME_GLIB macro. * src/gpgme.m4 (AM_PATH_GPGME_GLIB): Deprecated. -- GnuPG-bug-id: 7126 Signed-off-by: NIIBE Yutaka <[email protected]> ========================== So that users of GPGME will be able to notice libgpgme-glib will be possibly gone in future. They will be free to keep older gpgme.m4 or ther own patched version, though. --