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:
http://ervin.ipsquad.net/share/kde-platform-mobile/
Especially, the spreadsheet provides quite a lot of info:
kde_platform_internal_dependencies_overview.ods
(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
recommended.
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.
Regards.
--
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