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
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."
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.
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:
get to the point that we modularize, and Qt 5 becomes a reasonable target,
and we switch to Qt 5 as a dependency, at that point we'll start bringing
applications over [...] at least two more 4.x releases while changes
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.
Comments (5 posted)
Why don't we bring up IPv4 and just wait for IPv6 to happen in the
background? That's a great question; I'm glad I asked it. First,
it requires some small changes in NetworkManager's D-Bus interface
to add connected states for both IPv4 and IPv6 simultaneously so
that applications can listen for when each stack's connectivity is
available. That's trivial. It could be done tomorrow. It's not a
technical problem at all.
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
on why NetworkManager got slower
Apache is a charity conceived and constructed to provide code to
the world. We believe the best way to provide that code to
*everybody* is to do so under a permissive license. If we can
create a release of OOo, then we have performed our mission.
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.
-- Greg Stein
There comes a point with every shell script project where you
realise it would have been easier to use a real programming
language from the start. In this case, doing it in PHP with
pcntl_fork(), pcntl_exec() and pcntl_wait() would be a reasonable
solution. In my experience, you can't ask the question "how do I do
X in shell script" and expect to like the answer.
-- Tim Starling
(thanks to Sumana
Comments (none posted)
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
HTML files), and routing requests for dynamic content to a Web server (such
as the Apache HTTP Server).
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.
Comments (none posted)
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.
Full Story (comments: 41)
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
Full Story (comments: none)
The preliminary results of the 2011 GNOME Foundation board election have
been posted. The upcoming board will consist of Shaun McCance,
Germán Póo-Caamaño, and
Full Story (comments: none)
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
Full Story (comments: none)
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
Comments (25 posted)
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
" Also included are cross-device synchronization,
"personas," a new unified personal data manager, better plugin handling,
and more; see the release
Full Story (comments: none)
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.
Full Story (comments: 4)
Newsletters and articles
Comments (none posted)
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.
Comments (4 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>