May 3, 2006
This article was contributed by Tom Chance.
Ever since the first
technology
preview of Qt4, and probably even before, KDE 4 has been the subject of
wild speculation. The KDE Project actually discussed starting the KDE 4
branch as far back as August 2004 in a
birds of a feather
session. Two major releases later and the developers are finally buried
deep in their libraries, overhauling and rethinking the basics of their
desktop environment. By the time KDE 4.0 is released, which could be late
this year or early 2007, developers will have a lot of new toys to play
with.
To give you an idea of what KDE 4.0 will be like it's worth looking back at
KDE 2.0, which could almost have been described as a technology preview
rather than a complete desktop environment. Basic building blocks for KDE
first surfaced in that release, such as the KIOSlaves that enable all KDE
applications to handle all kinds of data transparently, from networked
machines accessed by ssh to man pages and Beagle searches. In KDE 3.0 those
technologies finally matured, and through the 3.x series we have seen the
developers realize their promise, creating the desktop that so
many know and love today.
KDE 4.0 is going to be a bit like KDE 2.0 - although far more useful and
mature - in that it will first expose a lot of infrastructure even if few
of the applications manage to exploit their potential. According to Aaron
Seigo, the core developer of Plasma:
Users are only likely to see applications using the infrastructure in
interesting ways by KDE 4.1, and then through the rest of the 4.x series it
will mature in the same way as 3.x. Hopefully it will happen with greater
speed than KDE 2 as we aren't starting completely from scratch
everywhere and we have a bigger development team. I'd expect early
adopters and "tourists" to jump into kde 4.0. but not school or enterprise
deployments.
Of course for developers this doesn't matter, the hype is all about the
technology, so even if Seigo is right and KDE 4.0 is a "first draft of a
post-technical preview type of release" there will be plenty to play
with. Don't say "vapourware" to a KDE developer!
Phonon, Solid, Plasma, Akonodi: these are the buzzwords
that give substance to the hype. Each mini-project is targeted at making
developers' lives easier, which is a big part of the KDE development
philosophy: give developers great tools and they'll make great
applications.
Phonon addresses the complexity of
audio and video functionality in applications, whether they're simple games
with silly beeps, instant messengers that need audio and video devices, or
complex mixing studios. The API should allow developers to get on with the
application and have a reliable, desktop-integrated multimedia framework do
the boring work. At the moment, for example, Kaffeine can embed videos in
Konqueror but it is prone to crashes because it has to make kernel-level
calls on its own. With Phonon, developers can do away with such hacks and
concentrate on one API if they want enhanced functionality.
The other design decision was to allow developers and users to use
different multimedia frameworks underneath Phonon - such as GStreamer, NMM,
MAS and Xine - rather than simply integrating one into the KDE
libraries. This decision, popular in Amarok, should promote more innovation
amongst developers and choice for users, though it will also undoubtedly be
more work than just adopting, say, GStreamer, as the GNOME developers
have done.
Solid takes up the challenge set by
Robert Love's Project
Utopia, and will try to make interaction with hot-pluggable devices and
networks more, well, solid. KDE already uses DBUS and HAL to provide basic
functionality that is almost equivalent to that found in GNOME, Microsoft
Windows and Apple MacOSX. But integration has been hard work, and in KDE
3.5 it can only shine through KIOSlaves and other "old" technology. The
main design goal of Solid is to give developers a single, consistent API so
that the desktop can become more flexible and integrated, much like Love's
goals with Project Utopia. It should be easy to make your application fully
aware of changes in network and hardware availability. The second design
goal is to avoid locking KDE into platform-specific technologies like HAL
(which currently only works with Linux).
Plasma will unite and rethink various
components in the desktop, including kicker and its various applets, SuperKaramba widgets, the K Menu
application launcher, the Run Command dialogue and the desktop space
itself. Eye-candy addicts will enjoy the more beautiful design that it
brings, but developers are more likely to appreciate the elegant API. Based
around a few basic elements,
Plasma should help
the desktop become a truly functional space rather than a dumping
ground for downloads and systray applets. The lofty ambition of Plasma is
to completely change the way we interact with the desktop, becoming
"workflow sensitive". Project-based collections, network aware widgets for
collaboration, interfaces that you can zoom in on to examine details and
zoom out of to gain overview and free-form layout of add-ons are all being
experimented with. But of course by KDE 4.0 it's likely to change
developers' mindsets more than the actual implementation of the desktop.
There are many other ideas floating around, such as Akonadi, a storage layer for PIM
(personal information management) applications. But, like Akonadi, many of
these ideas may
not appear until KDE 4.1. By October we should see a technology preview,
which will give developers their first chance to get hands-on experience
with which to judge the hype. In the meantime there's always SVN and KDE
2.0 to give you a sense of the excitement.
(
Log in to post comments)