Intended organization of KDE Frameworks

[Inge Wallin]

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?

> Throughout this example we will refer to the following graph:
> http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf

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.

> 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 label.

This is exactly what I'm talking about.

	-Inge

> = 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.
> 
> Regards.