## page was renamed from Kleopatra_hackability
= 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 [[http://techbase.kde.org/Getting_Started/Build/Windows/emerge|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:
 * Move it out of kdepimlibs into it's own repo with its own releases
    Rationale: It is fairly unrelated to kdepimlibs and sharing the build
    system with the dependencies of kdepimlibs led to the requirement of
    having a "KDEPIM_ONLY_KLEO" macro in there.
 * Add a minimum required gpgme version to avoid feature checks and according
 ifdefs.
    Rationale: Gpgme++ contains feature checks so that it can be used with old
    gpgme version. This complicates usage of gpgme++ and the gpgme++ code while
    there should not be a use case to build gpgme++ with a deprecated version
    of gpgme and no one maintains problems arising from that anyway.

I'd suggest to put it as language binding into gpgme, proper.  -- [[werner]] <<DateTime(2015-02-27T12:45:42Z)>>

== 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:
 * Remove this library altogether and move the remaining code (dataprovider) into 
   kdepim/libkleo/qgpgme

= 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:
 * DBus
 * sycoca (using kde's desktop file parser)
 * libattica
 * dbusmenu-qt

Possible improvements:
 * Evaluate kde-frameworks to only build / use the necessary parts of kdelibs
 * At least for windows it could be feasible not to depend on dbus / dbusmenu-qt
 and the kde system configuration. For IPC there is already assuan and the
 uiserver protocol and instead of a dynamic system configuration kleopatra could
 rely on a "hardcoded" set of available plugins.
 * Not sure where attica and dbusmenu-qt are actually used but it is doubtful that
 they are really necessary for kleopatra on Windows.
 * Add a kdelibs_only_kleo option or something like it in case of a monolithic build
 to reduce build-time dependencies.

= 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:
 * Use the UI Server protocol in other kdepim Applications instead of libkleo
 directly. This would reduce the bind between kleopatra and kdepim.
 * Move libkleo out of kdepim into it's own repository and guarantee
 some ABI stability for kdepim. This could be a candidate for kdepimlibs.

== 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:
 * It should be possible to remove boost altogether and replace it by Qt / C++11

=== 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:
 * Changing more and more STD library functions to qt class by class. This
 is too much to do it in one go.

=== 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 ;) )

* System configuration management
**KDesktopFile

* Selection dialogs
**kfiledialog.h
**kurlrequester.h
**kicondialog.h
**kicon.h
**kiconloader.h
**kshortcutsdialog.h

* For mobile ui (Possibly mobile UI only with kdelibs support)
**kdeclarativeapplication.h
**kdeclarativefullscreenview.h

* Shortcut / action helpers (should be replacable by QAction etc.)
**kacceleratormanager.h
**kaction.h
**kactioncollection.h

* Configuration files (should be replaceable by qsettings)
**kconfig.h
**kconfigbase.h
**kconfiggroup.h

* General KDE integration (could be replaced by qt)
**kglobal.h
**kglobalsettings.h
**kaboutdata.h
**kcomponentdata.h
**kapplication.h
**kcmdlineargs.h
**kuniqueapplication.h (uniqueness has to be adapted)
**kwindowsystem.h
**kstandardaction.h
**klibloader.h
**kshell.h

* Configuration plugins
**kcmodule.h
**kcmultidialog.h

* UI extensions over Qt
**kbuttongroup.h
**kpushbutton.h
**kdialog.h
**kedittoolbar.h
**kguiitem.h
**klineedit.h
**klistwidget.h
**klistwidgetsearchline.h
**kmenu.h
**kmessagebox.h
**ksplashscreen.h
**ksystemtrayicon.h
**kpagedialog.h
**kseparator.h
**knuminput.h
**ktextedit.h
**kxmlguiwindow.h

* Things unecessary with Qt5 / current cmake
**kdebug.h
**kdemacros.h ?
**kstandarddirs.h
**ksavefile.h
**ktemporaryfile.h
**kurl.h ?
**kprocess.h
**kmime/kmime_header_parsing.h (QtMimeDatabase? )

* Localization
**klocale.h

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:
 * Use Qt5 Replacements where possible to further reduce KDE dependencies
 * Make KDE integration optional and use Qt base classes in case KDE is not
 avialable.
 * Reduce optionality (Using Kleopatra without S/MIME backend on Windows ->
 Not supported. Etc..) As no one wants to maintain such configurations.

Localiziation:
 * Localization could be a problem for a kleopatra with optional kdelibs.
 A possible solution here would be to still use klocale from kde-frameworks so
 that the translations created by the community called KDE could be used.

Dbus:
 * The DBUS interface of kleopatra could be made optional. Or it could be
 replaced altogether by a wrapper that translates DBUS requests into the
 uiserver protocol so that dolphin for example could easily work with GPA.