Development
KDE moves forward on Frameworks
The KDE Project recently got together for a sprint called Platform 11 in Randa, Switzerland. One of the major decisions coming out of that gathering is to start work on the next KDE Frameworks — a set of high-level components for applications to use — immediately following KDE 4.7. What does this mean for the community? This time around, KDE won't be dragging users or application developers through the "big change" phase of underlying technologies for KDE.
The KDE Software Collection (KSC), what was once known simply as the K Desktop Environment, comprises everything from the KDE Developer Platform and the KDE Workspaces (such as the desktop and netbook workspaces) to KDE's applications. In the past, this entire collection has moved forward together — or tried to, at any rate. KDE developer Aaron Seigo describes major release cycles as "that 'big change' phase
" that included applications, desktop, and pretty much everything else.
That worked well enough when KDE was a smaller and less complex beast and "the overlap between 'people who work on kdelibs' and 'people who work on applications' was very high.
" As has been noted by many, however, that worked less well when work began on KDE 4:
Application developers either started porting "too" early or "too" late. Some jumped on the 4.x bandwagon quickly and suffered constant API drift, while others waited until "it" (whatever that meant) was stable (whatever that meant). Our users, in the meantime, drummed their fingers waiting for applications and workspace that they could use to be released. The need to get releases of applications out to users put unnecessary pressure on the library development process as well as the workspaces. They were all "welded together" in terms of release management. This reflected how we generally thought of the KDE codebase in general.
At Platform 11, KDE folks started thinking that having a "welded
together
" platform was not the best course of action. Putting
application development on hold while doing library development seems a bad
idea. It also happens that some libraries offered by KDE may not in fact be
of use only to KDE applications. In a discussion over Skype, Seigo noted
that the KDE Project wants to allow developers to choose KDE components
— such as the Solid Hardware
Library — without having to pull in all of the KDE libraries.
The trigger for this decision? As Sebastian Kügler wrote during Platform 11, the impetus to begin working on KDE's Frameworks starts with Qt 5. As Kügler notes, the fact that Qt 5 has a change in its binary interface, "is a good point in time to introduce some changes to our frameworks that are only possible if we change the ABI -- which Qt 5 will do for us anyway.
"
The decision has been made to start working on the next generation of KDE Frameworks following KDE 4.7 but not applications or workspaces. What are Frameworks? That's what is currently referred to as kdelibs, kde-runtime, kdepimlibs, kdepim-runtime, and kdesupport — essentially the core libraries for KDE user interface elements that are not provided by Qt. These are the libraries used by major KDE applications like the KDE Addressbook, KMail, and Dolphin.
Kügler also says that this will not only make it easier for
developers to use KDE Frameworks, but also lower the barrier for contributions to KDE, as well as making Frameworks more suitable for mobile devices. Seigo also emphasized the benefits for using KDE Frameworks on mobile devices such as phones, tablets, and set-top devices: "We want to make it possible that an application developer can use [just one component like Solid] a la carte with a clear set of dependencies
".
What Frameworks will be
According to Kevin
Ottens, the libraries will be sorted in two categories: the Framework
type and into Tiers based on the level of dependencies. The Framework types will be Solutions, OS integration, and functional Qt
Addons. Solutions would include a full technology like the Akonadi personal
information manager (PIM) or KIO, which provides access to files
stored locally or remotely. Solutions would also have libraries and
mandatory runtime
dependencies. OS integration Addons would either use a built-in feature for
an OS or implement it directly. The example given by Ottens is libkdatetime
which watches ktimezoned for time zone changes on Linux, but might use the Windows APIs directly. Finally, the functional Addons have no runtime dependencies at all. These would include new libraries like libkcore, which Ottens says "will contain the job classes, handling of command line arguments, text handling classes, file locking, and not much more.
"
![[Frameworks
dependencies]](https://static.lwn.net/images/2011/kde-frameworks-dependencies-sm.png)
The Frameworks will also be split into Tiers, with the first Tier
depending only on Qt itself, Tier 2 depending on Tier 1 frameworks, and
Tier 3 having dependencies on Tier 1, 2 and other Tier 3 Frameworks. So,
for example, Ottens says that window management would be a Tier 2, OS
integration Framework: "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.
" Ottens
also provides a graph (small version at right, click for a larger version) that visualizes the organization of existing KDE components.
The Frameworks plan also comes with new
rules, or at least more explicit rules, that codify (as Ottens says)
"changes to our habits which already happened a while ago during the
Qt 3 to Qt 4 port.
" This includes following the license policy,
following a consistent coding standard (preferably the kdelibs standard
— but that's not required), meeting the criteria of the Tier and Framework type, and maintaining binary compatibility until the next major release of KDE Frameworks.
Next steps
The next steps for the Frameworks plan is to keep working on libraries
until KDE 4.7 is branched, as well as trying to contribute to Qt 5. Seigo says that contributions to Qt 5 are going well so far, and that the Qt open governance process is working out satisfactorily. Though there is still work to be done and "lots of details left unresolved
" he says that there have already been examples of pushing development upstream to Qt rather than trying to implement or fix things in KDE. Seigo gave the example of a problem with keyboard shortcuts due to a limitation of Qt, and says that he pushed to fix it in in Qt rather than KDE: "in two weeks it was done and in Qt.
"
After the 4.7 branch has been created, David Faure says the plan is to create a new branch in kdelibs for the work on splitting kdelibs. This will still continue based on Qt 4, says Faure, because "we don't need Qt 5 to reorganize our own code
". At the same time, application developers will continue working in master with the kdelibs frozen.
How long will this go on? Seigo said that it will likely be at least two KDE releases before moving to Qt 5 and the new KDE Frameworks:
At the same time, KDE will continue bugfixes and features in kdelibs, but there will be no major changes.
When the time comes for applications to be ported to the new Frameworks,
Seigo says that the application developers will find "a cleaner API
and a much better dependencies story
" and users will see performance
gains — but there won't be a lot of changes due to Frameworks
themselves. Seigo also says that it will mean dramatic improvements for
"those using free software on tablets, set-top boxes
" and a
next-generation UI for mobile devices on top of Qt 5.
Naturally, mobile is another driver for the project re-thinking how it handles Frameworks. Seigo says that mobile and cross-platform development is very important for the KDE project and there will be a great deal of focus on Android and MeeGo for KDE.
Given the pain that users and application developers went through with the early releases of 4.x, this plan does seem to make a lot of sense for the project. Though it will take some time for it to come to fruition, there should be few downsides for application developers or users while other KDE developers focus on KDE Frameworks.
Brief items
Quotes of the week
But second, it requires applications to be smarter about what resources they require and to do smart things when those resources aren't available. And that apparently happens when solid gold pigs start dropping out of the sky. I hope you have falling-gold-pig insurance for your car. But app authors often don't make their applications smarter and more network aware because hey, that's more work for them, and hey, people haven't requested this yet, and hey, that's one more D-Bus API I need to depend on and I don't know what else.
Our charitable status specifically precludes us from competition. But would not want to compete, regardless. We will produce the best OOo we can. If yours is better, then we believe that is just fine. If you are able to use some portion of our code to make your job easier, then even better.
Apache traffic server v3.0.0 released
The Apache Software Foundation has announced the release of Apache traffic server v3.0.0. "Apache Traffic Server is a Cloud Computing 'edge' service, able to handle requests in and out of the Cloud, both by serving static content (images, JavaScript, CSS, and HTML files), and routing requests for dynamic content to a Web server (such as the Apache HTTP Server)." New features include better 64-bit support, better IPv6 support, web cache communication protocol (WCCP) support, a better plug-in API, and a number of performance improvements.
Apache votes to accept OpenOffice.org for incubation
Apache held a vote over the weekend to decide whether to accept OpenOffice.org as an Apache incubator project. The result was overwhelmingly in favor of the proposal, so the project will move ahead under the Apache Software Foundation. It will presumably be several months (or perhaps quite a bit more) before the project can get on its feet and potentially be considered for top-level project status.The Document Foundation's advisory board
The Document Foundation has announced the corporate members of its advisory board: Google, SUSE, Red Hat, Freies Office Deutschland e.V., Software in the Public Interest, and the Free Software Foundation. "The body represents The Document Foundation's sponsors, with each sponsor having the right to one representative. They will provide the future Board of Directors with advice, guidance and proposals, and will consult regularly on the further development of the Foundation and its associated projects."
Results from the GNOME Foundation board election
The preliminary results of the 2011 GNOME Foundation board election have been posted. The upcoming board will consist of Shaun McCance, Emmanuele Bassi, Stormy Peters, Bastien Nocera, Brian Cameron, Germán Póo-Caamaño, and Ryan Lortie.Kontact Suite 4.6 released
The KDE project has announced the release of version 4.6 of the Kontact Suite. "Among the most noticable improvements are faster email notifications, vastly improved performance for IMAP email accounts, and improved interoperability with other applications that consume contacts, calendars and other groupware-related information."
PathScale EKOPath 4 compiler suite open-sourced
PathScale has announced that its EKOPath 4 compiler suite will be turned into an open-source project. "This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers." All that's missing is an actual link to the source; it appears to be showing up on github; the license seems to be GPLv3.
SeaMonkey 2.1 released
Version 2.1 of the SeaMonkey browser (and more) is out. "Building on the same Mozilla platform as Firefox 4, it delivers the latest developments in web technologies such as HTML5, hardware acceleration and improved JavaScript speed." Also included are cross-device synchronization, "personas," a new unified personal data manager, better plugin handling, and more; see the release notes for details.
Upstart 1.3 released
Upstart 1.3 is out; it includes a number of enhancements developed for the Ubuntu "natty" release and more. This is the first release under the maintainership of James Hunt, who has implemented a new review policy aimed at, among other things, ensuring that copyrights for contributions have been appropriately assigned to Canonical.
Newsletters and articles
Development newsletters from the last week
- Caml Weekly News (June 14)
- PostgreSQL Weekly News (June 12)
- Python-URL! (June 14)
- Tcl-URL! (June 13)
Taylor: Benchmarking compositor performance
On his blog, Owen Taylor investigates compositor performance. "Now, this immediately gets us to a sticky problem: there are no mechanisms to throttle application frame rate to the compositor frame rate on the X desktop. Any app that is doing animations or video, or anything else, is just throwing frames out there and hoping for the best. Really, doing compositor benchmarks before we fix that problem is just pointless. Luckily, there's a workaround that we can use to get some numbers out in the short term — the same damage extension that compositors use to find out when a window has been redrawn and has to be recomposited to the screen can also be used to monitor the changes that the compositor is making to the screen. (Screen-scraping VNC servers like Vino use this technique to find out what they need to send out over the wire.) So, our benchmark application can draw a frame, and then look for damage events on the root window to see when the drawing they've done has taken effect."
Page editor: Jonathan Corbet
Next page:
Announcements>>