Porting KActivities to KF5 (Re: Review Request: Add Activity Awareness to KFilePlaces* Widget (OnlyInActivity))

[David Faure]

On Tuesday 02 October 2012 19:47:31 Ivan Čukić wrote:
> > making a frameworks branch in the kactivities repo is fine. the library
> > should indeed be easy to port.
> 
> The core library currently uses only KDebug, i18nc and KUrl.

-> qDebug, QUrl, and either tr or the ki18n framework, depending on the 
complexity of the translated stuff, and possibly for a more automatic loading 
of translation catalogs.
 
> The data models library, the service and the workspace addons use more
> stuff.
> 
> So, the core library (that is meant to be used in most applications (and
> KFP) could be easily ported to be Qt-only.
> 
> The rest will need to be dependent in some level from kde libs.
> 
> OTOH, the service uses the sycoca for plugins, kstandarddirs, kjob,
> kwindowsystem. And some service plugins use more things.

-> kservice, QStandardPaths, kcoreaddons, kwindowsystem.

> Should the repository be split into several ones with various levels of
> dependencies or something?

No, I don't think so. It's one piece of technology (one framework), it should 
come in as one module, to ease development, testing, and releasing.

The difference in dependencies still means that the developer of an application 
who wants to depend on the core kactivities library, will not link to 
additional libs, so that's fine. If he's getting kactivites from his system 
then he won't care that the 'service' has more deps, and if a user installs 
the app, he would need the runtime deps anyway (= the service and its deps).

In short, the whole "libs / runtime" split idea from KDE4, is gone in KF5, 
replaced with the more modular "here is all you need for technology xyz".

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5