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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
