KDE Platform Profiles

Kevin Ottens ervin at kde.org
Mon Apr 12 12:15:08 BST 2010

Gooooood (not-so-)morning(-anymore) kde-core-devel!

This mail is the result of discussions we had during Tokamak4 to downsize the 
KDE Platform to fit on more constrained devices. That of course will break 
some assumptions we had in the past. We had some findings, and made a draft 
plan of action to bring our platform forward in the mobile space.

It contains the feedback collected on kde-maemo and from a few key persons. 
That's why we're now presenting it on kde-core-devel to get further 
constructive feedback if need be.

I'd like us to reach consensus if some disagreements arise. Since this 
proposal got peer reviewing already, and was well accepted, I hope that only 
small issues will arise with it now.

That was the executive summary, now comes the long version. :-)

=== Present situation ===
We estimated the dependencies (cutting at Qt and system libs) to run a KDE 
application which would use the full platform to be around 48 MB maximum 
(release build, 64 bits arch was used as reference). We counted kdesupport, 
kdelibs and kdebase runtime for that, but we excluded icons and translations, 
also assuming only one style and desktop theme were provided.

After that, we graphed the dependencies of the libraries. The simplest cases 
were solved using ldd, otherwise we used a script for the bigger dependency 
hungry libraries.

The raw data of those efforts can be found there:
Especially, the spreadsheet provides quite a lot of info: 

(I'm obviously not going through the whole lot of data in this mail as that 
would be too long, and this mail is quite long already)

=== Goals and strategy ===
Rumors are that for Meego, there would be a minimum space guaranteed for third 
parties, and this minimum would be 32 MB. So indeed we need to have strategies 
to reduce the amount of the platform brought on the device when the user only 
install a couple of apps. And obviously the more different apps, the more 
frameworks you'll need, we can't really get around that, but at least we can 
enter something like the Meego platform by providing the minimal set of 
features and growing as needed by the user.

Then, what becomes important is to streamline the dependencies within the KDE 
Platform so that less storage, memory and bandwidth consumption is generated 
by pulling a KDE application. That also means that we need to clearly 
communicate about the packages that should be split from kdelibs and friends.
Instead of a single kdelibs binary package, we need one per kdelibs submodule 
(kdecore, kdeui, solid...).

Strategy 1: Reduce KDE Platform's internal dependencies, and make sure the 
packaging is more modular, so that a small set of apps is less likely to bring 
up the whole thing.

Assessing that we want to remove of the internal dependencies is obviously not 
enough to reduce the size of the platform as advertised to OEMs and third 
parties. We identified that some of the platform is likely to be less useful 
depending on usage of the device it is deployed on. So we aim at tagging parts 
of the platform as "suitable for X". Which of course raised the question of 
the different usages.

We identified that the view on the platform should not be as binary as 
splitting it into "Full Desktop" and "Mobile Phone" but rather more finely 
grained. We refer to the current full scale setup as "Desktop profile". The 
other end of the scale is the "Mobile profile". The middle sized edition is 
named the "Tablet profile" (at least for now, although admittedly that's the 
best name we could come up with so far).

The usage pattern would be the following:
 - Desktop: Extensive and power user usage as we know it today (the full game: 
multimedia, any content reading, complex content editing);
 - Tablet: Mostly Internet connected devices for multimedia usage, reading 
content, some content editing;
 - Mobile: Very constrained devices, multimedia usage, content reading, very 
light content editing.

Tablet profile:
Most of the modules are labelled as "tablet suitable". Some dependencies are 
simplified if they don't remove advanced features. Mostly the full game, but 
obvious bloat or modules which provide very advanced features are not 
labelled. In short: aiming for very low feature loss, but some modules aren't 

Mobile profile:
Only the most useful modules for a smart phone are labelled as "mobile 
suitable". Dependencies are simplified as much as possible, which may go as 
far as replacing some parts of the libraries with fallbacks for system 
libraries and minor breakage of BC at defined points (only in this profile, 
not affecting the other ones). Some features obviously get lost.

Strategy 2: Label only parts of our platform as suitable for a given usage 
profile. Have three different profiles: Desktop, Tablet, Mobile.

With those two strategies, the idea is to provide packages for all of kdelibs, 
but in a more modularized way (via packaging, and by cleaning up internal 
dependencies). Then we can recommend a core set of libraries that should be 
available as base platform depending on the usage profile. This will help 
packagers and application developers when choosing their dependencies for non-
desktop projects.

=== Action Plan ===
* We need to communicate with packagers in order to see more fine grained 
packages built, at least for the non-desktop variant of distros. That might 
even reach out to desktop distros, which is maybe a good thing, but that's not 
our main focus. kde-packager got already contacted by Frederik (although I 
didn't see any feedback coming from this list yet).

* We propose adding a CMake variable to choose the platform profile. 
KDE_PLATFORM_PROFILE would be one of Desktop, Tablet, Mobile. We already have 
a first proof of concept patch for that under Alexander's review, subject to 
changes. Note that said variable is a high level one setting defaults for the 
low level variables used within out libs (e.g. if KDE_PLATFORM_PROFILE=Mobile 
then in libplasma we'd set a "PLASMA_NO_KDEWEBKIT" variable to true which 
would be used to avoid the kdewebkit dependency).

* Applying dependency reduction in code is possible with the platform profile.

* Fix issues found applicable to all profiles. Even the Desktop will benefit 
from cleaner dependencies.

* On the Mobile profile, in process ioslaves are desirable and it may even be 
feasible to replace KIO internals by system (Qt) calls. It needs to be 
evaluated, and KIO hacked that way.

(We mention KIO here, because it is a special case: it drags in a lot of 
dependencies and KIO usage leads to process switches that are expensive.)

Please note that at this stage, we're focusing mainly on providing the base 
platform components focusing on resource consumption. Making the GUI parts of 
kdelibs suitable for different form factors still has to be investigated. As a 
first step, we probably need a switch to make sure KDE application don't 
enforce the use of their KStyle on mobile platforms and use the Qt one as 
specified by OEM.

=== BIC concerns ===
Some dependencies can be cut by moving symbols within kdelibs further down in 
the dependency chain. This type of change is hardly "#ifdef'able" so it would 
affect also the Desktop profile. This is binary compatible on Linux and 
Windows but unfortunately not BC on Mac. Apparently it wouldn't be such a 
problem in practice to make this kind of changes as KDE/Mac is still young, 
and not tagged stable. The timeframe to decide on that is short though, we 
still have to contact the KDE/Mac people ASAP.

There are some (soon to be) unused classes in pimlibs which bring extra 
dependencies (note that we had only a quick look at kdepimlibs so we started 
below in the stack). Since we don't want to break BC on the Desktop and Tablet 
platforms, there will be no changes. But, the Mobile platform comes with much 
more constrains and there are no kdelibs yet there, so no compatibility can be 
broken. We would suggest some BC breakage here to allow slimmer dependencies 
in this case.

In particular, it would be possible to remove deprecated classes to reduce 
library size. It might also be worth it to let OEM selectively activate that 
for their platform even in the Tablet profile.

To summarize, here are the different profiles, and the type of actions they 
would imply:
                       | Desktop | Tablet | Mobile  |
Communicate with       |    X    |   X    |     X   |
packagers              |         |        |         |
Cut deps               |         |   X    |     X   |
low feature loss       |         |        |         |
Cut deps               |         |        |     X   |
feature loss           |         |        |         |
KIO "in process"       |         |        |     X   |
"klauncher less KDE"   |         |        |         |
Removing deprecated    |         |        |     X   |
classes from the build |         |        |         |
Others BIC changes     |         |        |         |
to reduce deps or      |         |        |         |
footprint              |         |        |         |

For more details on the changes we plan to the platform, you can find them in 
the spreadsheet I pointed out above. Note that we identify some of them which 
in fact also provide some improvements and flexibility to the Desktop case. 
Those changes we'll start working on now like any other contribution, the plan 
and strategies proposed here are up for discussion and comments.

Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100412/2e6ab43f/attachment.sig>

More information about the kde-core-devel mailing list