w32: GPA use of libgpgme-glib
NIIBE Yutaka
gniibe at fsij.org
Thu May 21 03:15:46 CEST 2026
Hello,
Werner Koch <wk at gnupg.org> 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 <gniibe at fsij.org>
==========================
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.
--
More information about the Gnupg-devel
mailing list