Kleopatra hackability (especially with regards to windows)

Kleopatra is often critizied for being to big and to hard to build with an entry level for new hackers that adds uneccessary barriers for contributors.

This page is intended to take a look at the status quo (as of KDE Platform 4.13 (KP4)) and offer suggestions for potential improvements with the goal of increasing the stability and making kleopatra as an uiserver for gnupg more attractive for hackers and users.

tl;dr;

Kleopatra could be made into a Qt only application with optional dependencies to KP4. So that if it is build as part of a distribution including KP4 (KDE Apps on Windows / GNU/Linux Distributions focusing on Plasma) it would still integrate with KP4 settings / Ui etc. But when built as a standalone application it would no longer pull in the whole kdelibs stack.

Build system

Currently you need a KP4 development environment to build / hack kleopatra which is especially hard to come by for Windows. Currently Kleopatra is built using the KP4 Windows build system emerge as this contains the necessary buildscripts for the required kdelibs dependencies. Reducing the KP4 dependencies would make it easier to set up a cross compile environment for Kleopatra and build kleopatra from source as a part of the Gpg4Win installer creation. This would bring the added benefit of making Kleopatra's build much more transparent and easier to reproduce.

Kdepimlibs

There is already a kdepim_only_kleo build option that reduces much of the dependencies needed to build kdepimlibs and only builds the reduced set actually needed for Kleopatra. This reduces the pressure to move the libraries necessary for kleopatra out of kdepimlibs. But as shown below this is only gpgme++.

gpgme++

Only depends on C++.

Possible improvements:

qgpgme

Only depends on gpgme++ and Qt. There does not appear to be any reason for this anymore. It only contains only two qt wrappers around GpgME::DataProvider and an "eventloopinteractor".

The eventloopinteractor is no longer necessary on windows as gpgme is used multithreaded there. It might still be used on GNU/Linux but I failed to find it's usage there.

Possible improvements:

kdelibs

Kleopatra depends on the monolithic kdelibs (no kdelibs_only_kleo) at least in the build system but it only uses symbols from a small subset of the kdelibs libaries: libkdecore, libkdeui, libkmime, kded_globalaccel and libkcmutils.

Ideally the build would then only depend on the third party libraries necessary to build these but as of KP4 v4.13 the kdelibs build system does not support to build such a reduced set. For example there is a dependency to have qsslsocket available during build for which you need a qt build that had openssl headers available. So without actually needing this you need to include openssl in the build system.

Dependencies pulled in by kdelibs:

Possible improvements:

kdepim

As with kdepimlibs there is already a build option to reduce the build time dependencies for kleopatra. This is already a great help building kleopatra only from the kdelibs repository.

Libkleo

Other applications in kdepim make use of libkleo but Kleopatra only slightly uses libkdepim (apparently only the progressmanager)

Possible improvements:

Kleopatra

Kleopatra has a fairly unique (at least inside of kdepim) mix of using STD library functions combined with boost c++ extensions and Qt. This increases the entry barrier / knowledge necessary to happily hack away in kleopatra as a prospective hacker needs knowledge not only of Qt and some basic C++ (as is enough in most other places in KP4) but additionally has to understand design patterns and code based on Stdc++ and Qt.

Boost usage

Boost usage could be removed or replaced either with C++11 features (shared pointer, lambda etc.) or by equivalent structures in Qt. It is also probable that some boost features could just be replaced by simpler code which would be easier to maintain / understand while only increasing the overhead a bit.

Possible improvements:

STD Library usage

While there should not be a necessity to use the std c++ library as much when there is a library like Qt already available, Kleopatra extensively uses the std data structures std::vector, std::map and their functions instead of their Qt variants.

Possible improvements:

Kdelibs

As written above kleopatra does not use kdelibs very heavily. Mostly kdeui, the kde config management is used.

(based on:)

find kleopatra libkleo -name \*.cpp -o -name \*.h | xargs grep -h -i include | grep k | grep < | sort -u | grep -v kleo

(All <> headers included that contain a k ;) )

Porting Kleopatra from Qt4 to Qt5 would already make some of those classes unecessary. kDebug could be replaced by QDebug, there is now a QStandardPaths that could replace kstandarddirs, QSaveFile is there etc. etc. And several extensions made their way into Qt5 so that there should be no large (and irreplacable) loss of functionality when removing KP4 extensions like KUrl.

Possible Improvements:

Localiziation:

Dbus:

KleopatraHackability (last edited 2014-07-03 15:12:04 by bernhard)