|  |  | News |  | | It'll be a topic at Platform 11, it's a topic that is ever more important KDE developers working on constrained mobile devices, it's a topic that app developers moving to or already using Qt are wondering about more and more: How modular are KDE's libraries?
The short answer is this: more than they used to be .. but with a lot of room for improvement.
We have a growing number of libraries that only depend on non-GUI parts of Qt such as KDECore, Solid and Attica to name three off the top of my head. We have more than only rely on Qt and no other KDE libraries. This is rather better than the "big glop" of libraries in kdelibs in KDE 3.x days. Are we getting the most out of this? Sadly, not really.
Here are three avenues of thought for those of us involved with writing, maintaining and/or packaging KDE's libraries to consider that could help improve things:
Packaging With More Modularity
While most of our downstream packagers tend to split up applications into separate packages, KDE's libraries tend to come in big chunks that reflect the source packages. On OpenSuse, the distribution I'm using, there are two main packages: libkde4 and kdepimlibs4. The both contain large collections of libraries that are vaguely related to each other. The downside to this is that if a Qt app developer wants to use Solid, they end up having to pull in all of libkde4.
Open questions:
- What can KDE library developers due to improve this situation through build system or module layouts?
- What information or other help for packager would help drive more modular packaging?
- What libraries are most worth modularizing into their own packagers for application developers?
Identifying and Justifying Dependencies
Even if libraries were split out more efficiently, there are some interesting limits to that right now due to dependencies between our libraries. In the "pre-4" days we really didn't pay much attention to inter-library dependencies, nor did we have many good reasons to do so. Today, with a more modular Qt, a growing Qt app ecosystem and targets like mobile, we now do have some pretty good reasons to do so.
Let's take libsyndication as an example. libsyndication is the library used by applications such as Akregrator and Plasma DataEngines to fetch and process RSS feeds. It depends on KIO, a library which pulls in a fair number of dependencies with it. If we examine what it uses KIO for, we find out that KIO is used in just one file: dataretreiver.cpp. Within that file, it is used for one purpose only: to fetch feeds over the network, usually (exclusively?) it seems via http. It would be possible to use QNetworkAccess for this instead, which would use KIO in a KDE Workspace, turning KIO into a runtime dependency driven implicitly by the user. Without those few lines of KIO usage, libsyndication would only require KDECore, QtCore, QtNetwork, QtDBus and zlib.
Combined with more modular packaging, this would open libsyndication to a much broader Qt app development audience, with no loss of functionality. Of course, libsyndication is just one example (it came up in an email conversation with a Qt and Gtk+ app developer last night, actually). How many other KDE libraries have similar unnecessary dependencies?
We don't want to sacrifice integration or functionality, but there seems to be a lot of possibility here. How many can we identify? How many identifications can we turn into realized improvements?
To Split, To Aggregate?
Another avenue for exploration is the lines along which our libraries are split. In working towards the first version of KDE Platform 4, we re-arranged the classes in KDECore and KDEUi so that KDECore had not GUI dependencies. This brought a very nice division of tasks between the two. There is so much more opportunity for this, however.
KDEUi itself is an interesting, though highly complex, example: it has all sorts of useful UI bits in it, some of which are applicable to QtQuick applications and some which only make sense to QWidget based ones. Is this an opportunity?
Nepomuk libraries in kdelibs combine both data and user interface elements: does it make sense to split that into two, so more Qt apps could take advantage of Nepomuk with fewer dependencies?
How about libplasma, which has a number of both data and user interface elements in it? It's still an unresolved question as to whether we'd gain anything from splitting out the data elements (DataEngine, AbstractRunner, etc) from the user interface bits, or along which lines such a split would actually happen. It might make more sense to cleave it into "QtQuick-appropriate" and "QGraphicsWidget" parts.
This becomes a balancing act: too many libraries and load times go up; too many libraries and maintenance of the code as well as of packaging and building goes up; too few libraries and the audience decreases due to lack of clear focus and odd dependency chains.
... and more?
There are indeed more topics to mull over, such as the relationship between kde-runtime and kdelibs. What goes into kde-runtime and what goes into kdelibs is pretty well defined these days: build dependencies go into kdelibs, runtime dependencies go into kde-runtime. However, when it comes to dependencies and use cases between these two modules, what then?
Or how about the icons situation: we have a large chunk of very high quality icons .. but do we need to install them all together, or can they be modularized as well, e.g. into "in the icon spec", "also needed by kdelibs", "needed in the workspace" and "used by specific apps"?
How do we best prep the KDE Platform for QtQuick? Several parts of that answer were worked on at the recent KDE Mobile developer sprint, and we have code to show for it. Where do we go from there?
If you are a library developer, a packager or an app developer: what topics related to modularity can you think of?
These are the kinds of questions that swirl around the exciting life and times of a KDE library developer. It's the kind of querying we'll press upon ourselves in the amazing alpine environment of Switzerland's Valais region in June. Our work in 2011 will be tinted by the answers and ideas that sprout out of these lines of thought.
If you've ever pondered getting your hands dirty and your feet wet (or other body-in-substance metaphors ;) with KDE platform and library development, there's probably never been a better time to do so. For the curious, we coordinate most day-to-day development of the libraries on kde-core-devel@kde.org, use the "kdelibs" group on reviewboard.kde.org for patches and hang out in #kde-devel on irc.freenode.net.
For those of us already foot, knee, waist or neck deep in the code, we owe it to our selves, our code and our users to think about the above and take action to push the state of our art. It's a path to more users of our libraries (which also means more contributors!) as well as a way to embrace more of the Qt ecosystem and in turn be embraced right back.
BackRead original postSend to a friend
Add comment
Add comment
Show all posts
|
|
| |
|
slashdot it
digg it
del.icio.us
Facebook
reddit
StumbleUpon
Twitter
