--nextPart2681108.ox6nhqRf7U Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gooooood (not-so-)morning(-anymore) kde-core-devel! This mail is the result of discussions we had during Tokamak4 to downsize t= he=20 KDE Platform to fit on more constrained devices. That of course will break= =20 some assumptions we had in the past. We had some findings, and made a draft= =20 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.= =20 That's why we're now presenting it on kde-core-devel to get further=20 constructive feedback if need be. I'd like us to reach consensus if some disagreements arise. Since this=20 proposal got peer reviewing already, and was well accepted, I hope that onl= y=20 small issues will arise with it now. That was the executive summary, now comes the long version. :-) =3D=3D=3D Present situation =3D=3D=3D We estimated the dependencies (cutting at Qt and system libs) to run a KDE= =20 application which would use the full platform to be around 48 MB maximum=20 (release build, 64 bits arch was used as reference). We counted kdesupport,= =20 kdelibs and kdebase runtime for that, but we excluded icons and translation= s,=20 also assuming only one style and desktop theme were provided. After that, we graphed the dependencies of the libraries. The simplest case= s=20 were solved using ldd, otherwise we used a script for the bigger dependency= =20 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:=20 kde_platform_internal_dependencies_overview.ods (I'm obviously not going through the whole lot of data in this mail as that= =20 would be too long, and this mail is quite long already) =3D=3D=3D Goals and strategy =3D=3D=3D Rumors are that for Meego, there would be a minimum space guaranteed for th= ird=20 parties, and this minimum would be 32 MB. So indeed we need to have strateg= ies=20 to reduce the amount of the platform brought on the device when the user on= ly=20 install a couple of apps. And obviously the more different apps, the more=20 frameworks you'll need, we can't really get around that, but at least we ca= n=20 enter something like the Meego platform by providing the minimal set of=20 features and growing as needed by the user. Then, what becomes important is to streamline the dependencies within the K= DE=20 Platform so that less storage, memory and bandwidth consumption is generate= d=20 by pulling a KDE application. That also means that we need to clearly=20 communicate about the packages that should be split from kdelibs and friend= s. Instead of a single kdelibs binary package, we need one per kdelibs submodu= le=20 (kdecore, kdeui, solid...). ****** Strategy 1: Reduce KDE Platform's internal dependencies, and make sure the= =20 packaging is more modular, so that a small set of apps is less likely to br= ing=20 up the whole thing. ****** Assessing that we want to remove of the internal dependencies is obviously = not=20 enough to reduce the size of the platform as advertised to OEMs and third=20 parties. We identified that some of the platform is likely to be less usefu= l=20 depending on usage of the device it is deployed on. So we aim at tagging pa= rts=20 of the platform as "suitable for X". Which of course raised the question of= =20 the different usages. We identified that the view on the platform should not be as binary as=20 splitting it into "Full Desktop" and "Mobile Phone" but rather more finely= =20 grained. We refer to the current full scale setup as "Desktop profile". The= =20 other end of the scale is the "Mobile profile". The middle sized edition is= =20 named the "Tablet profile" (at least for now, although admittedly that's th= e=20 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 ga= me:=20 multimedia, any content reading, complex content editing); - Tablet: Mostly Internet connected devices for multimedia usage, reading= =20 content, some content editing; - Mobile: Very constrained devices, multimedia usage, content reading, ver= y=20 light content editing. Tablet profile: Most of the modules are labelled as "tablet suitable". Some dependencies ar= e=20 simplified if they don't remove advanced features. Mostly the full game, bu= t=20 obvious bloat or modules which provide very advanced features are not=20 labelled. In short: aiming for very low feature loss, but some modules aren= 't=20 recommended. Mobile profile: Only the most useful modules for a smart phone are labelled as "mobile=20 suitable". Dependencies are simplified as much as possible, which may go as= =20 far as replacing some parts of the libraries with fallbacks for system=20 libraries and minor breakage of BC at defined points (only in this profile,= =20 not affecting the other ones). Some features obviously get lost. ****** Strategy 2: Label only parts of our platform as suitable for a given usage= =20 profile. Have three different profiles: Desktop, Tablet, Mobile. ****** With those two strategies, the idea is to provide packages for all of kdeli= bs,=20 but in a more modularized way (via packaging, and by cleaning up internal=20 dependencies). Then we can recommend a core set of libraries that should be= =20 available as base platform depending on the usage profile. This will help=20 packagers and application developers when choosing their dependencies for n= on- desktop projects. =3D=3D=3D Action Plan =3D=3D=3D * We need to communicate with packagers in order to see more fine grained=20 packages built, at least for the non-desktop variant of distros. That might= =20 even reach out to desktop distros, which is maybe a good thing, but that's = not=20 our main focus. kde-packager got already contacted by Frederik (although I= =20 didn't see any feedback coming from this list yet). * We propose adding a CMake variable to choose the platform profile.=20 KDE_PLATFORM_PROFILE would be one of Desktop, Tablet, Mobile. We already ha= ve=20 a first proof of concept patch for that under Alexander's review, subject t= o=20 changes. Note that said variable is a high level one setting defaults for t= he=20 low level variables used within out libs (e.g. if KDE_PLATFORM_PROFILE=3DMo= bile=20 then in libplasma we'd set a "PLASMA_NO_KDEWEBKIT" variable to true which=20 would be used to avoid the kdewebkit dependency). * Applying dependency reduction in code is possible with the platform profi= le. * Fix issues found applicable to all profiles. Even the Desktop will benefi= t=20 from cleaner dependencies. * On the Mobile profile, in process ioslaves are desirable and it may even = be=20 feasible to replace KIO internals by system (Qt) calls. It needs to be=20 evaluated, and KIO hacked that way. (We mention KIO here, because it is a special case: it drags in a lot of=20 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= =20 platform components focusing on resource consumption. Making the GUI parts = of=20 kdelibs suitable for different form factors still has to be investigated. A= s a=20 first step, we probably need a switch to make sure KDE application don't=20 enforce the use of their KStyle on mobile platforms and use the Qt one as=20 specified by OEM. =3D=3D=3D BIC concerns =3D=3D=3D Some dependencies can be cut by moving symbols within kdelibs further down = in=20 the dependency chain. This type of change is hardly "#ifdef'able" so it wou= ld=20 affect also the Desktop profile. This is binary compatible on Linux and=20 Windows but unfortunately not BC on Mac. Apparently it wouldn't be such a=20 problem in practice to make this kind of changes as KDE/Mac is still young,= =20 and not tagged stable. The timeframe to decide on that is short though, we= =20 still have to contact the KDE/Mac people ASAP. There are some (soon to be) unused classes in pimlibs which bring extra=20 dependencies (note that we had only a quick look at kdepimlibs so we starte= d=20 below in the stack). Since we don't want to break BC on the Desktop and Tab= let=20 platforms, there will be no changes. But, the Mobile platform comes with mu= ch=20 more constrains and there are no kdelibs yet there, so no compatibility can= be=20 broken. We would suggest some BC breakage here to allow slimmer dependencie= s=20 in this case. In particular, it would be possible to remove deprecated classes to reduce= =20 library size. It might also be worth it to let OEM selectively activate tha= t=20 for their platform even in the Tablet profile. To summarize, here are the different profiles, and the type of actions they= =20 would imply: =2D---------------------------------------------------| | Desktop | Tablet | Mobile | =2D---------------------------------------------------| Communicate with | X | X | X | packagers | | | | =2D---------------------------------------------------| Cut deps | | X | X | low feature loss | | | | =2D---------------------------------------------------| Cut deps | | | X | feature loss | | | | =2D---------------------------------------------------| KIO "in process" | | | X | "klauncher less KDE" | | | | =2D---------------------------------------------------| Removing deprecated | | | X | classes from the build | | | | =2D---------------------------------------------------| Others BIC changes | | | | to reduce deps or | | | | footprint | | | | =2D---------------------------------------------------| =46or more details on the changes we plan to the platform, you can find the= m in=20 the spreadsheet I pointed out above. Note that we identify some of them whi= ch=20 in fact also provide some improvements and flexibility to the Desktop case.= =20 Those changes we'll start working on now like any other contribution, the p= lan=20 and strategies proposed here are up for discussion and comments. Regards. =2D-=20 K=E9vin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com --nextPart2681108.ox6nhqRf7U Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEABECAAYFAkvDAL0ACgkQB0u7y43syeJleQCfQDRk1bxzdpoMT+k7sM4emJRY sPYAnA8zNxv2KAppY6ylJ4VqE7vKLzNv =UDUl -----END PGP SIGNATURE----- --nextPart2681108.ox6nhqRf7U--