Frameworks 5

Wednesday, 25 September 2013  |  Smartboyhw

A recent Dot article explained changes in the KDE release cycle that will be happening with the upcoming introduction of Frameworks 5. The changes to KDE's core libraries are enough to warrant a name change from 'Platform' to 'Frameworks'. This article provides some background, an overview of the changes, and the benefits and improvements that can be expected from KDE Frameworks 5 for the entire Qt community. A later article will address Frameworks 5 benefits for KDE developers.

The KDE libraries are currently the common code base for (almost) all KDE applications. They provide high-level functionality like toolbars and menus, spell checking and file access. Currently, 'kdelibs' is distributed as a single set of interconnected libraries. Under the KDE Frameworks efforts, these libraries are being methodically reworked into a set of independent, cross platform modules that will be readily available to all Qt developers.

The KDE Frameworks, designed as drop-in Qt Addons, will enrich Qt as a development environment with functions that simplify, accelerate and reduce the cost of Qt development. For example, KArchive (one of the first Frameworks available) offers support for many popular compression codecs in a self-contained and easy-to-use file archiving library. Just feed it files; there's no need to reinvent an archiving function.

The transition from Platform to Frameworks has been in progress for more than 2 years and is guided by top KDE technical contributors. Previews of the first Frameworks are expected to be released in December 2013.

Introducing Frameworks 5

Frameworks 5 consists of functional components and are structured in categories and tiers, based on their dependencies.
Categories The Frameworks can be divided into three categories:
  • Functional elements have no runtime dependencies. For example, KArchive (mentioned above) handles compression and decompression for many archive formats transparently and can be used as a drop-in library.
  • Integration designates code that requires runtime dependencies for integration depending on what the OS or platform offers. For example, Solid supplies information on available hardware features and may require runtime components to deliver some of the data on some platforms.
  • Solutions have mandatory runtime dependencies. For example, KIO (KDE Input/Output) offers a network-transparent virtual filesystem that lets users browse and edit files as if they were local, no matter where they are physically stored. And KIO requires kioslave daemons to function.

Frameworks 5 separates the KDE libraries into modules with clear dependencies.

Tiers Frameworks are further divided into tiers, which relate to link-time dependencies. Tier 1 Frameworks can be used independently, while Tier 3 Frameworks can depend on other Tier 3 Frameworks and tiers below them. The diagram shows dependency chains.

The Frameworks are also separated by respecting core/gui distinctions and the different GUI technologies. So it's not uncommon to find a core, a gui and a widget module relating to a given Framework (e.g KConfigCore vs KConfigGui). This way third parties can use only the parts they need and avoid pulling unwanted dependencies on QtGui.

Show me the code

To give an idea of what is available in Frameworks 5, a cross-section of Frameworks from different tiers is presented below. These are in various stages of completion and many more are under development.

Functional Frameworks These Frameworks are independent. They have no runtime dependencies, but offer drop-in functionality.

  • KArchive is a Framework that deals with popular compression technologies such as ZIP, 7ZIP and TAR archives, and offers a compression QIODevice for gzip, bzip2 and xz. It will extract whatever file it's given.
  • KPlotting is a simple plotting Framework that offers anti-aliasing, stacking and updating. It takes care of transformation from the data's natural units to screen pixel coordinates and adds axis labels with tickmarks and tick labels.
  • Threadweaver makes writing multi-threaded code easier by handling background jobs. Unlike QThreadPool, it features job dependencies and has done signals per job, as well as a global jobsDone signal. It allows threads to be suspended and aborted easily and depends only on QtCore.
  • KConfig is a Framework to deal with storing and retrieving configuration settings. It features a group-oriented API. It works with INI files and XDG-compliant cascading directories. It generates code based on XML files.
  • Extra itemmodels include:
    • recursive filtering model for tree views
    • checkable proxy model for trees and lists
    • proxy model for restructuring a tree into a list
  • KCoreAddons include:
    • KJob: a base class for async APIs
    • file handling classes: directory watching, backup handling, auto save files
    • on-disk sharing of cached data between applications
    • text handling classes: split strings at word boundaries and add ellipsis

Integration Frameworks These have platform-dependent runtime dependencies for system integration.

  • Sonnet has a speller and background checker, as well as widgets and spellcheck and configuration dialogs. It is plugin-based and can work with aspell, hspell, hunspell and enchant.
  • Solid offers hardware detection and can inform an application about storage devices and volumes, CPU, battery status, power management, network status and interfaces, and Bluetooth. For encrypted partitions, power and networking, running daemons are required.

Solution Frameworks These require their own runtime daemons to function properly.

  • KIO lets the user browse and edit files the same way, locally and remotely. It features asynchronous jobs in separate processes and supports a large number of protocols including (s)ftp, samba, webdav and nfs, many compressed file formats, thumbnails, audio-cd music extraction, trash and fish (a file management view over an ssh connection).
  • KService is the framework that provides advanced features for plugins, including locating them on disk based on queries. It's useful for component-based architectures where it pulls mandatory runtime dependencies. It also provides capabilities for finding the applications associated with a particular type of file, such as identifying which application is the user's preferred PDF viewer.

History of KDE Libraries

When KDE began more than 15 years ago, development was application-driven. Libraries were an afterthought, intended to share work, making development easier and faster. Libraries were added based on simple rules. For example, if a particular functionality was used in more than one place, it was put into a shared library. Sometimes the functionality was an addition to existing Qt classes, other times new libraries were developed for functions such as hardware discovery (Solid) or file access (KIO). The libraries had the additional benefit of improving overall functionality, consistency and stability. These overall improvements provided substantial value, so developers were encouraged to create and use more common library components.

Issues The libraries have grown organically over the years, and for KDE application developers, they were and continue to be useful. However, they are not very fit for use outside of traditional Linux desktop applications. The KDE libraries were designed to be used all at once in one complete bundle (known as "kdelibs"). There were many inter-dependencies between functions. Moreover, launching an application built on the KDE Platform brought in many runtime elements.

For these reasons, it is hard to re-use KDE Platform 4 components outside of KDE applications. With the emergence of mobile platforms, this is an important consideration. On a modern desktop computer, the footprint of the KDE libraries and the runtime components is not very significant, but things are different on mobile or embedded devices. Developers have become more and more interested in using only the useful bits and pieces in their code. They do not want to pull in a lot of other unneeded components that generate their own dependencies, possibly hard to fulfill on a target platform. Splitting up kdelibs into independent modules would greatly improve their standalone utility.

Qt and Frameworks A group of core developers produced a plan for achieving a greater degree of modularity. From the beginning, KDE has relied on Qt as an upstream resource. So KDE libraries contain many pieces that would be useful in Qt development, if modular capabilities from kdelibs were available. Making these functions available adds value to Qt as a premier development platform. This was a major driver of the decision to make KDE library functions more modular. The introduction of Qt's Open Governance model in late 2011 offered the opportunity for KDE developers to get more closely involved with Qt, KDE's most important upstream resource. And this has produced benefits that are available to every Qt user. Among the new features added by KDE developers are improvements to Qt's platform adaptations, a command line parser, file-type determination, file locking, and a series of X11-related features.


Randa 2011 - click for larger
Frameworks 5 These contributions to Qt form the basis for further modularization of the KDE libraries. The libraries are moving from being a singular 'platform' to a set of 'Frameworks'. This is the fifth such major KDE architectural transition, and the reasoning behind the name "KDE Frameworks 5". This shift also means that KDE technology will be no longer tied to a single platform, desktop or community. Instead it is a comprehensive set of technologies that becomes available to the whole Qt ecosystem. KDE libraries will become easier to use, and will enrich Qt as a development environment.

Frameworks 5 was started in the spring of 2011 at an architectural strategy gathering in Randa, Switzerland. Developers from various KDE areas and projects (including several developers from the GNOME project) spent a week in discussion considering the impacts of the Qt 5 release. KDELIBS classes were pulled apart into pieces destined for upstreaming to Qt, deprecating or refactoring. The result of these efforts was a roadmap to Frameworks 5. Sebastian Kügler's blog post provides further insights about the work involved with Frameworks 5.


Kévin Ottens

Collaboration and Roadmap

KDE Frameworks 5 is currently under development by a team of about 20 developers led by Kévin Ottens and David Faure. About half are supported by the four companies that are actively involved in the development of Frameworks 5.

Work on KDE Frameworks 5 is coordinated at the weekly Tuesday 4 p.m. (CEST; UTC+2) meetings on #kde-devel (freenode IRC). Reports from the meetings are sent to the Frameworks-devel mailing list. The meetings consist of announcements at the beginning, after which participants share what they worked on during the previous week and what they plan to tackle in the upcoming week. Work is planned and documented on the wiki. In addition to IRC, coordination takes place over the kde-Frameworks-devel mailinglist. The mailing list is also a place to inquire about particular KDE functionality that may be available for Qt development.


David Faure - photo by Martin Klapetek (CC BY)

The project of transitioning to KDE Frameworks 5 is essentially a matter of refactoring a large, mature code base, and work has been in progress for more than two years. A preview release is planned for December 2013, with a final release in the first half of 2014. To give those interested a sense of the expected level of quality, documentation and testing, two Frameworks are planned to be released as 'final' with the December preview release: KArchive and KThreadWeaver. (For developers using Qt 4, KArchive is available as a download from David Faure. It works on Unix-like systems and reportedly on Windows too.)

Current state and code

The current state of Frameworks 5 development is available in the KDE Frameworks repository. The KDE Community wiki has an overview of the functionality offered by the Frameworks. The wiki also has a Frameworks page, which includes a dashboard with the current status of Frameworks 5.0.

Inqlude.org is another resource for Qt developers. Inqlude offers a view from the Frameworks perspective. The goal of this site is to provide a comprehensive cross reference of KDE Frameworks for Qt developers who are looking for ready-made functionality for their applications. The site, currently in Alpha, is scheduled for an overhaul during October. Additional contributors are warmly welcomed.

Article by Howard Chan and Jos Poortvliet, input from core frameworks developers including David Faure, Kévin Ottens and Sebastian Kügler.

Comments:

why isn't Sonnet a 'functional framework' ? - Ian Monroe - 2013-09-25

Is the separation between functional or integrative just on whether they have plugins loaded at runtime or not? Deploying Sonnet is trivial.

logind and ConsoleKit - Olav Vitters - 2013-09-25

How does KDE frameworks 5 deal with logind, ConsoleKit, etc?

my guess would be that a - kevkrammer - 2013-09-25

my guess would be that a functional framework needs to work on all platforms (due to no external dependecies), while an integrational framework might not

I am not sure there is a - kevkrammer - 2013-09-25

I am not sure there is a library respectively a framework interacting with those. Probably done by KDM and/or the Plasma workspace shell

integration frameworks - aseigo - 2013-09-25

Integration frameworks provide integration with services on the system. Solid integrates with hardware awareness features on the native OS, while sonnet provides access to the system's spell checking services. The functional frameworks provide a set of functionality in and of themselves that does not change or necessarily rely on operating system / platform service infrastructure. They may, of course, use external libraries (beyond Qt) but these would not be platform services.

session management / user access - aseigo - 2013-09-25

A lot these features are really only relevant to the workspace, so integration exists in Plasma. Frameworks is not concerned with things like managing sessions, for instance. There are Frameworks, such as KAuthorized which allows applications to (transparently to them) tie into system services such as PolicyKit. It really comes down to: do applications need to worry about this feature set, or is it really a workspace (e.g. desktop shell) issue? The latter all fall into the category of Plasma and are entirely unrelated to Frameworks. Frameworks and Plasma Workspaces are separate things.

QML - Maksim - 2013-09-26

Is QML interpreted each time on run, or only once on build time? I'm quite not happy with kde 4 then talking about laptop up time from battery. As I correct understand for Qt5 interfaces will only on QML. It should have performance, memory and battery up time penalty.

ThreadWeaver - David Gil - 2013-09-26

"To give those interested a sense of the expected level of quality, documentation and testing, two Frameworks are planned to be released as 'final' with the December preview release: KArchive and KThreadWeaver" I'd say it's ThreadWeaver, not KThreadWeaver. Good article!! :-) Cheers!

Other Qt desktops - cloose - 2013-09-26

With the merge of Razor and LXDE-Qt, it would be great to get them also on board of this project. IMHO, a framework created and maintained by all Qt desktop projects would be a huge gain for the Qt community. Are there any discussions about this already?

Quite the opposite.., qt5 and qml = performance improvements - Shaun Reich - 2013-09-26

While it is true that interfaces are interpreted at runtime, this mostly only applies to plasma and the workspace. Additionally, the migration to qml not only makes designing interfaces that behave and look as we intend, it does also bring a lot of performance improvements with this. Traditionally, with c++, the prior methods of rendering interfaces, even in plasma, were not properly hardware accelerated. That meant burning cpu time to render updates when the gpu can do it far far faster and go back to power saving states. Qt5 brings a lot of improvements in this area, due to implementing items on a scene graph(especially with qt5.2),reduces texture switches, over draw, and reduces draw calls made. Also with QML, it is far easier and more practical to load only what we need when we need it. This simply wasn't practical in c++'s methods of forming interfaces. So basically all of these changes are significant improvements in performance, resource usage, and interface formation. So really your worries are pretty much non existent, I would say. Not only that, but we've really come a long way, able to squash bugs just so much faster, and reduce the maintenance burden of previous c++ code, when it comes to user interfaces in the worskpace(mostly plasma, but also parts of kwin)

At load time - kevkrammer - 2013-09-27

QML is currently parsed at load time but there are plans to enable it at build time as well. Qt5 interfaces can use QtWidgets, QtQuick and any other UI technology they would like to use. Their developers can code them in C++, use something that generates C++, QML, or any other approach their chosen UI technology supports

Yes - kevkrammer - 2013-09-27

The folks from Razor/LXDE are following the development of frameworks quite closely.

Thanks for the article - Richard__ - 2013-09-28

Thanks for the article, I really enjoyed reading it, especially the "Introducing Frameworks 5" and "History of KDE Libraries" part.

Broken link - A. - 2013-12-11

In the last section ("Current state and code"), the link https://projects.kde.org/projects/kde/kdelibs/repository/show?rev=Frameworks gives me a 404 error.

link fixed - kallecarl - 2013-12-11

Thank you. The link is fixed.

"Places" in file dialogs - Zeemvel - 2015-03-11

"Places" in file dialogs seems broken now, all my favorites in there are gone and there is no more button to add them. Will this be fixed? Thanks!