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.cu...@kde.org, http://cukic.co/ gpg key id: 850B6F76 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
