GpgME++ and QGpgME now Released as part of GpgME
aheinecke at intevation.de
Wed Sep 21 15:46:43 UTC 2016
I'm pleased to announce that the C++ bindings for GnuPG's GPGME library and
the Qt Job API for GpgME++ (QGpgME) that was previously in Libkleo are now
part of the upstream GPGME repository and have been released today with
* With Applications 16.12 there will be no more release of pim/gpgmepp
* Libkleo will still be released with the focus of providing common classes to
be used in different Applications working with GnuPG based crypto. The backend
abstraction and Chiasmus support (which was untested for years and probably
didn't work anymore) will be removed.
For Packagers this will also mean that you are likely (at least until we are
done adding support for GnuPG's latest features in KMail / Kleopatra) to
require a very new GPGME (not GnuPG itself) version that is built with the qt
and c++ binding enabled. Thanks to the CI Team we already have GPGME on
Sorry about that, but this will mean that there are two PIM libraries fewer
(yay) and in the long term that these bindings are maintained by the GnuPG
Project. (And there will be many less Ifdefs in our code as we previously
supported multiple versions of GPGME in GpgMEpp).
Another bad thing: As a concession to the GPGME maintainer I ported the build
system back in time to autotools *brr*. But then your GnuPG Packagers are
probably more used to that anyway ;-). At least the libraries still install
CMake Config files. So cmake based users will be able to easily switch from
Both libraries should be coinstallable by default. But the header names of
GpgMEpp will conflict with the headers from KDE4's kdepimlibs/gpgme++.
QGpgME is now basically a Tier 0 (requires qtbase only) library. It provides a
consistent Job based API and is heavily used by KMail and Kleopatra as the
highest Abstraction for crypto.
Please not that because QGpgME was mostly part of Libkleo (although
confusingly libqpgme was part of gpgmepp) it is licensed under the GPLv2+ and
not under LGPL as the rest of GPGME.
There was some inconsistent error handling code in libkleo that required
KMessageBox and Ki18n in the past. This as been removed and applications need
to handle these errors themself.
The API is mostly untouched but functionality moved from the Libkleo Namspace
to the QGpgME Namespace.
Instead of using the CryptoBackendFactory / Protocol to obtain jobs you now
Yes we use a different casing for GPGME everywhere, sorry, historic reasons,...
This should be mostly a drop in replacement for KF5Gpgmepp. There were some
API breaks to get rid of boost (in favour of C++11) so you might need to
replace some boost::shared_ptr with the standard equivalent.
For the Assuan based API (I am not aware of a use outside of Kleopatra) there
was a larger break to port from the deprecated auto_ptr to unique_ptr.
We'll start switching to the new Library soon in Kdepim there are already some
branches prepared for this. For developers I'll try to add gpgme to kdesrc-
build so that the transition will not break your development builds.
My task for the transition is: https://phabricator.kde.org/T3158
Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 630 bytes
Desc: This is a digitally signed message part.
More information about the release-team