Splitting KActivities, 2nd attempt...

[Ivan Čukić]

Hi everybody,

We have a few problems at the moment because all the activities
components are in a single repository. Sometimes dependencies of the
service creep up into the library, builds break because components
that are meant only for Plasma start requiring Qt versions that Plasma
require, while KF5 requirement is lower, and similar.

The way I want to split the repository is as follows:

- KActivities framework (essentially a Tier 1, integration or solution, all OSs)
- kactivitymanagerd (service, kcm settings module, dolphin plugin;
officially linux-only)
- KActivitiesStats library (library meant for Plasma and friends, so
linux-only, no need for it to be a framework)
- kactivities QML imports (this could be in kamd repository, but it
will require KAStats at some point, and it is not really a part of the
service)

An alternative would be to have the dolphin and the qml imports in a
kactivities-workspace repo, or moved to existing workspace
repositories. IMO, the KCM module belongs with the service - it is its
main interface outside of Plasma.


More details on what is what:

- KActivities framework allows applications to report what they are
doing and to react to when the user changes her activity. On systems
that do not run kamd, it behaves like there is only one activity, so
everything works without the need of ifdeffing-out the kactivities
calls;
- kamd - the service that tracks which application opens which
documents, contacts and other resources, and manages the activities.
It comes with a kcm module to create and remove activities, to set the
'no-tracking' mode etc., and with the dolphin plugin to link files to
activities (something like adding favourites);
- KAStats library provides the way to applications to retrieve (in
some way) the statistics collected by kamd. It is currently
'experimental' and used only in Plasma. Since it does not build by
default from kactivities repo (plasma-desktop keeps a copy of the
library called kactivitiesexperimentalstats so that it does not
collide with the future released one) it will not break anything if it
is moved to another repo;
- QML imports - the name says it all.

The releases of other components would be synced to Plasma, not KF5.


Reasons for the split:

- Different deps for different components. Compiler version, Qt
version, KFrameworks used, other libraries (boost) etc. Only the
framework actually follows the KF5 requirements. Other parts follow
the plasma reqs.
- Dependency problems - currently we have a potential circular dep
problem due to KAStats being in plasma-desktop, and kactivities QML
imports wants to use it.
- KCM settings, dolphin plugin etc. are not really a part of the framework
- Simpler build system (compiler features checks, etc.)


Potential problems:

- More work for packagers (though, with benefits that they do not need
to know about -DKACTIVITIES_LIBRARY_ONLY and similar flags)
- It will require more planning on my side regarding syncing the
updates between the library and the service (the service already keeps
back-compatibility, but new library features will need  to wait until
the new service is released).



Cheerio,
Ivan

--
KDE, ivan.cukic at kde.org, http://cukic.co/
gpg key id: 850B6F76