Hello lists, <disclaimer> 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. </disclaimer>
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 graph: http://files.kde.org/ervin/platform11/kde-frameworks-matrix.pdf == 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: http://files.kde.org/ervin/platform11/kde-frameworks-dependencies-plan.pdf 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. = 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. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
