Intended organization of KDE Frameworks

Hello lists,

As, Sebas pointed out we've been meeting here to work on plans to improve our
frameworks offering leading to the decision of leaving the current "kdelibs
model" behind and prepare for a more modular suite named KDE Frameworks. If
you didn't read his email yet, please do so before going back to this email.

Currently, our set of base frameworks is mainly kdesupport, kdelibs and
kdepimlibs. Apart from kdesupport which is now splitted, kdelibs and
kdepimlibs are collections of libraries. That leads to hiding internal
dependencies in those modules, especially in kdelibs, and some of the
libraries are more dumping grounds than proper frameworks with a purpose. The
new model we're moving to will help us have clearer dependencies and push us
toward a more modularized offer. Among other benefits, it will make it easier
for third party developers to use our frameworks, and it should also make
contributions easier.

= Overall organization =
In the new KDE Frameworks organization, we're aiming at sorting our libraries
along two axes. The first axis deals with the runtime dependencies (organized
in Framework Types) while the second axis deals with the link time
dependencies (organized in Tiers). The position of a library along of those
two axis is mainly a stamp or a label we put on a library, it will come with
responsibilities though, and will help us find how to improve a library.

In the following lines, we're going to describe the rules summarized in this
<a href="" title=""></a>

== Framework Types ==
We will have now three Framework Types: Solutions, Qt Addons (OS Integration)
and Qt Addons (Functional). They mainly differ in their runtime dependencies.

* Functional Qt Addons shall not have any runtime dependency (think for
instance of a split libkconfig, it would drag no runtime at all);

* OS Integration Qt Addons can have optional runtime dependencies, if the OS
supports the feature they shall use OS facilities, otherwise a runtime
dependency might be used to implement the feature (think for instance of a
split libkdatetime, it would use ktimezoned on Linux, but on Windows it would
directly use Windows APIs);

* Solutions implement a full technology or stack, including a library and
mandatory runtime dependencies: plugins, servers, etc. (think for instance of
Akonadi, KIO or Soprano).

== Tiers ==
The goal of Tiers is to clarify the link time dependencies of our libraries.

* Tier 1 frameworks depend only on Qt itself and no other Qt based framework;

* Tier 2 frameworks depend only on Qt and Tier 1 frameworks;

* Tier 3 frameworks can depend on any Tier 1, 2 or 3 frameworks.

== Look & Feel + Consistency ==
Obviously the naming of that category is difficult. It will contain all the
frameworks which won't fit in the nice categories described above. The purpose
of those frameworks will be:
* to ensure the behavior and look consistency between KDE Applications;
* to integrate KDE Applications with the Workspaces.

= Examples and Aims =
Maybe after reading through all that, it still seems too abstract, that's
understandable, so in this part of the email we'll cover a partial example of
what our new organization will look like. Keep in mind that it is non
exhaustive, and describes the intended situation rather than the current code
structure. Work will be required to get there.

Throughout this example we will refer to the following graph:
<a href="" title=""></a>

We will quickly present a few examples for some of the ten categories:

* Tier 1, Functional Qt Addon: kcore
libkcore will be a new library adding a few features on top of libQtCore. In
particular, it will contain the job classes, handling of command line
arguments, text handling classes, file locking, and not much more. Because of
that, it will be fairly self contained and will depend only on libQtCore
granting it the Tier 1 and Functional labels.

* Tier 2, Functional Qt Addon: kconfig
libkconfig will be a new library containing our good old KConfig* classes. It
uses QtCore, but also the file locking mechanisms provided by libkcore. It
brings no runtime payload. Because of that, it will be granted the Tier 2 and
Functional labels.

* Tier 2, OS Integration: Window Management
The window management features of kdeui will be split out into their own
library. It will depend on libkgui and Qt, granting it the Tier 2 label. As it
provides integration with the OS which in particular might require a runtime
payload (although not in that particular case), it is granted the OS
Integration label.

* Tier 3, Solution: KIO Widgets
The current libkio will be split in several parts, one containing the core
features, the one we're considering here will contain features like KRun and
the other widgets you might want to use with KIO Jobs. It will depend on
another Tier 3 framework (Services Traders) granting it the Tier 3 label, it
is then allowed to depend on Tier 1 frameworks like solid, or Tier 2 like
kconfig. Also, it is part of a complete stack, including KIO Core and a
runtime payload (klauncher + ioslaves), that's why it is granted the Solution

= Conclusion =
I hope this email will help clarify what we're aiming at with the KDE
Frameworks. We're confident it is a move for a clearer situation regarding the
dependencies of our frameworks. Also, it will hopefully give us a framework
(no pun intended!) to help us identify which ones can be improved and made
easier to use.



Re: Intended organization of KDE Frameworks

By Inge Wallin at 06/07/2011 - 02:39

On Tuesday, June 07, 2011 00:04:41 Kevin Ottens wrote:
Very good start, although I can sympathize with the pains of the translators.
Were there any translators at the sprint?

May I suggest that everything with widgets in it is moved to another "Look &
Feel + Consistency" box? In the figure I can see kwidgets, color widgets,
jobs widgets and possibly kgui. The reason is that our technology is starting
to be used in places where qwidgets aren't even used, and it makes zero sense
to link to a library with widgets in them on e.g. a MeeGo smartphone.

On the other hand, the dialogs and widgets implement a functionality that we
would like to have available to those platforms (in many cases). This means
that we would want to provide equivalent or similar dialog on other platforms
that are consistent with that platform and HIG in question.

So a well defined API that applications could use, and a well isolated way to
include a set of implementations would be nice. We are dealing with exactly
this type of problems in Calligra right now, where our tools are linked with
the data shapes, but some parts of the tools don't make sense on e.g. touch
screens. One example of that is docker windows. It would be a pity to build
in another one of these hardcoded assumptions on the graphic environment now
that we are doing this nice refactoring effort.

This is exactly what I'm talking about.


Re: Intended organization of KDE Frameworks

By Aaron J. Seigo at 06/07/2011 - 04:21

On Tuesday, June 7, 2011 08:39:58 Inge Wallin wrote:
the best way to make this happen is to create a concrete plan and propose it.

for inspiration: at Platform 11, a couple of teams spent entire days going
through every single class in kdelibs and entry in kde-runtime to catalog what
is what. the results are on spreadsheets:

<a href=";hl=en_US&amp;authkey=CKTcjdgP" title=";hl=en_US&amp;authkey=CKTcjdgP"></a>
<a href=";hl=en_US&amp;authkey=CI_3zNMC" title=";hl=en_US&amp;authkey=CI_3zNMC"></a>

these were then used to build up answers that are workable and make some

it's work, but necessary work to turn a good ambition such as yours into a
reality. we'll have a fair amount of time to do the actual work after 4.7
branches, but we need to have concrete plans so we know what we are trying to

Re: Intended organization of KDE Frameworks

By Albert Astals Cid at 06/06/2011 - 18:17

A Monday, June 06, 2011, Kevin Ottens va escriure:
Shall i read from this graph that we will not be providing translation support
for solid, date and time, kauth, kgui and kwidgets (since it would mean a T1
component depending on another T1 component)?


Re: Intended organization of KDE Frameworks

By Kevin Ottens at 06/06/2011 - 19:14

On Tuesday 7 June 2011 00:17:23 Albert Astals Cid wrote:
Well, obviously a Tier 1 framework would have to use tr() instead of i18n()
for its translation needs. AFAIK that shouldn't be a big issue as libsolid is
already in that situation. We're aware that our own translation system
provides more feature, but at the level of Tier 1 frameworks the user messages
should be simple enough to get away with using tr().


Re: Intended organization of KDE Frameworks

By Albert Astals Cid at 06/06/2011 - 19:26

A Tuesday, June 07, 2011, Kevin Ottens va escriure:
Are we still going to use .po or you plan on us moving to Qt translation

Yeah, and totally fails to follow KLocale setting of wheter to use KB, KiB,

I disagree, time and date formatting is anything but simple.


Re: Intended organization of KDE Frameworks

By Kevin Ottens at 06/06/2011 - 19:38

On Tuesday 7 June 2011 01:26:17 Albert Astals Cid wrote:
Well, I honestly don't know what awesome magic you used for libsolid, so for
me it's "the same recipe". Note that it'll happen mostly for Tier 1 frameworks

Right, however there's also a plan ATM to get the settings between KLocale and
QLocale shared. John is working on that right now, so it depends a bit on the
outcome, in any cases the situation is likely to improve on that particular

If really needed it'll get into Tier 2 then, no big deal. Again, the graph
presented is non exhaustive and makes some assumption about goals we set. If
there's a blocker along the way we'll reevaluate, it's not meant to be read as
done deal or set in stone.


Re: Intended organization of KDE Frameworks

By John Layt at 06/07/2011 - 06:41

On Tuesday 07 Jun 2011 00:38:58 Kevin Ottens wrote:
I'm drafting an email right now to set out some of my plans, but I'm well
aware I need to sit down with Albert at Desktop Summit to discuss how
translation fits into all this to make sure we lose none of the features we
currently have.


Re: Intended organization of KDE Frameworks

By Albert Astals Cid at 06/07/2011 - 03:46

A Tuesday, June 07, 2011, Kevin Ottens va escriure:
Unfortunately that is not possible. Right now Solid is translated using .po
but that only works in KDE applications because you have a KGlobal+KLocale
around that loads .mo files (compiled .po), hijacks Qt calls and maps them to
the .mo contents. Without a KGlobal+KLocale around that will not work.

This means that if you want Tier 1 frameworks to be translatable you need
either to teach Qt to understand gettext files natively or to make Tier 1
frameworks use pure based Qt/Linguist solutions which does not fit either in
what scripty is able to do neither in what our translators are used to.


Re: Intended organization of KDE Frameworks

By Ingo =?iso-8859... at 06/26/2011 - 15:45

On Tuesday 07 June 2011, Albert Astals Cid wrote:
AFAICS, Tier 1 frameworks don't provide any UI. IMHO they shouldn't
provide any user visible texts either. Just like UI this should be
outsourced to Tier 2 or 3 if necessary at all.


Re: Intended organization of KDE Frameworks

By =?UTF-8?Q?Nicol... at 07/02/2011 - 22:31

On 6/26/11, Ingo Klöcker < ... at kde dot org> wrote:
Many classes that one may reasonably think that use no translations,
like KPluginLoader, contain many user-visible strings. The class
reports errors via an "errorString" that the host app may then display
to the user.

Re: Intended organization of KDE Frameworks

By David Jarvie at 07/05/2011 - 07:18

On Sunday 03 July 2011 03:31:07 Nicolás Alvarez wrote:
Perhaps some of these classes could return error codes instead in order to qualify for Tier 1, and an additional Tier 2 class could provide the message texts which relate to the error codes.

Re: Intended organization of KDE Frameworks

By Albert Astals Cid at 06/26/2011 - 16:12

A Sunday, June 26, 2011, Ingo Klöcker va escriure:
Localization is not only about user visible texts, It is also about kconfig
having per language keys, it is about kstandarddirs::locate being able to find
localized icons, etc.


Re: Intended organization of KDE Frameworks

By Ingo =?iso-8859... at 06/27/2011 - 16:18

On Sunday 26 June 2011, Albert Astals Cid wrote:
I hear you, but by the definition of Tier 1 none of this can be used in
Tier 1 frameworks because "Tier 1 frameworks depend only on Qt itself
and no other Qt based framework".

Of course, this means that Tier 1 frameworks will be very low-level and
not offer some of the features we are used to in KDE libraries. But
that's exactly the point of Tier 1.


Re: Intended organization of KDE Frameworks

By Aaron J. Seigo at 06/28/2011 - 12:27

On Monday, June 27, 2011 22:18:08 Ingo Klöcker wrote:
other possibilities include:

* approving a "tier 1 dep exception" for localization; this was discussed at
Platform 11 as possible, though probably not preferable to:

* improving localization in Qt5 and merging in the best bits of KDE in this
regard there

there is alread some work going on for his which started at Platform 11. i
don't know what the current status of it is and how many of the localization
bits will land in Qt5, but this would be, imho at least, the best possible

Re: Intended organization of KDE Frameworks

By John Layt at 06/28/2011 - 17:57

On Tuesday 28 Jun 2011 17:27:35 Aaron J. Seigo wrote:
That would be me then :-) I'll have some emails for the list shortly on these
subjects including the discussions at QtCS. In short, most of what we want
looks likely to happen.

However, its not all about the Locale stuff I'm doing, stuff like the
KStandardDirs::locate is more about paths and platform plugins which guys like
David are looking into. I'm not sure when a library would need Icons, but
they will sometimes need Translation and Locale for error messages, and paths
to grab other stuff.

So yeah, a lot of this depends on getting stuff into Qt to work better with
KDE as a supported Platform.


Native gettext support for Qt (was: Intended organization of KDE

By Manuel "Sput " ... at 06/07/2011 - 05:51

Wouldn't that be a sane thing anyway? I never really understood why Qt needs
to have its own, completely incompatible translation system while the rest of
the world happily uses gettext. In Quassel, this has hurt us a lot because we
cannot easily tap into existing translation teams and resources. As it turns
out (and understandably so), translation teams like that of KDE have their
established workflows centered around gettext, and are not too willing to
start using Linguist or other tools to translate an application that is Qt-

A while ago, we have tweaked Quassel's build system to accept .po files and
generate .qm files at build time from those. But this is error-prone and
requires tools (e.g. lrelease) that are not found on all systems by default.
Still, offering gettext translations has significantly increased translator
contributions for us...

This whole situation is such a mess that we actually looked into taking KDE's
i18n stuff and friends, and port it over to Qt (by way of deriving
QTranslator), just to be able to reap the benefits of KDE's translation
resources. Turned out that i18n() depends on too much of other kdelibs stuff
to make that a feasible, maintainable option though.

I really think one should look into the opportunity given to us by the move to
Qt5 to bring native gettext support to Qt, and retire the old tr() system, or
at least make it just another option. This would tremendously help Qt-based
apps to get good localization support, and even more so applications like
Quassel that can be built with and without KDE support.

~ Sputnick

Re: Native gettext support for Qt (was: Intended organization of

By John Layt at 06/07/2011 - 07:20

On Tuesday 07 Jun 2011 10:51:29 Manuel "Sput" Nickschas wrote:
We discussed translation briefly at Platform 11 and Qt moving to or supporting
.po is something we really want to push for at QCS. I really hope we have
some people knowledgable about translation at QCS able to argue the point,
otherwise please let me know the key arguments in favour.

As part of the whole modularisation discussion the idea was also floated that
if Qt is unwilling to move to .po then our translation module could be an
attractive option for other projects looking for a sane and fully featured
transaltion solution.


Re: Native gettext support for Qt (was: Intended organization of

By Albert Astals Cid at 06/07/2011 - 13:57

A Tuesday, June 07, 2011, John Layt va escriure:
Not sure about other people knowledgable about translation but i won't be at


Re: Native gettext support for Qt (was: Intended organization of

By John Layt at 06/08/2011 - 15:27

On Tuesday 07 Jun 2011 18:57:22 Albert Astals Cid wrote:
Looks like I have a crash course in gettext versus tr before the summit then
:-( I'm pretty sure we can't convince them to drop tr entirely, but do you
think it's feasible for Qt to support loading translations from both systems
(obviously not both at the same time)?



Re: Native gettext support for Qt (was: Intended organization of

By John Layt at 06/08/2011 - 15:27

On Wednesday 08 Jun 2011 19:48:30 Mark wrote:
Interesting, but not very active, GPL3 so not something that could be used in
library code, and lacking all our cool advanced features. But just goes to
show we're not the ony ones wanting gettext with Qt.


Re: Native gettext support for Qt (was: Intended organization of

By Albert Astals Cid at 06/08/2011 - 16:29

A Wednesday, June 08, 2011, John Layt va escriure:
FWIW all our advanced features are not because of gettext use but because of
our code on top of it.


Re: Native gettext support for Qt (was: Intended organization of

By Andreas Pakulat at 06/07/2011 - 06:39

On 07.06.11 11:51:29, Manuel "Sput" Nickschas wrote:
One reason I guess is that gettext is only easily available on
Linux/*nix, but at least on Windows and MacOSX is an unknown thing. So
by having their own solution Qt apps work the same way on all platforms.