The K Desktop Environment (KDE)
is one of the largest and most successful Open Source projects. KDE
users number in the millions and they depend on the stability of
KDE every day. With such success, it would be easy for the KDE
developers to sit back and savor their accomplishments. After all,
the original goal for KDE described an intuitive and easy to use
Unix desktop. With the award
winning 1.1 release, KDE fits that bill almost perfectly.
There is still work to be done, however. The current development
pace has increased, rather than diminished.
This article will try to describe some of the major features
that users can expect out of KDE 2.0. The over-riding trend that
carries though all of these changes is increased configurability,
power, and ease of use to both the end-user and the developer.
KOM/OpenParts — Ready for the Big
Time
Two of the biggest “new” features of KDE 2.0 involve the
KOM/OpenParts CORBA component layer. KOM/OP and KOffice aren’t
really new — they have been in development for over a year — but
only recently have they moved past the experimental or test phase
into real usability. With the extensive KOffice experience, KOM/OP
is now ready for complete integration into all aspects of KDE.
KOM/OP
KOM/OpenParts is a distributed object component layer built on top
of CORBA. It is quite possibly the single biggest change between
the current and the future KDE. In a nutshell, the CORBA/KOM/OP
integration means that KDE applications will be able to inter-
communicate and reuse each other’s functionality to a very high
degree.
The amount of CORBA integration will vary by application. The
biggest current and future user is the KOffice suite (more on that
later). A close second is the Konqueror file manager/web browser.
Actually, it’s not quite accurate to describe Konqueror only in
those terms anymore as it does so much more.
Konqueror is built on the OpenParts part of KOM/OP. A “Part” is
a CORBA object that can be “embedded” into other CORBA
applications. The effect is similar to DCOM, OLE, and OpenDoc. For
instance, when Konqueror comes upon, say, a JPEG graphics file, it
checks with the mime-type registry to see how to handle it. The
mime-type dictates that an “image viewer” is needed with certain
properties. Konqueror then forwards these properties to the KDE
trading service. The trading service “finds” an OpenPart — a
CORBA-enabled application — that fits those properties and
activates it. The activated OpenPart image viewer will then open up
“embedded” into Konqueror. Konqueror’s menus and toolbars will be
replaced (or supplanted) with the Part’s menus while it is
displaying the image. From the user’s point of view, it will look
like the image viewer is part of Konqueror, not an entirely
separate application.
This leads to an almost “plug-n-play” method of using
components. In the past, a file manager would typically have the
image viewing code hard-coded into the application or linked
through a library. Changing this code meant, at the least,
recompiling everything. At the most, it could mean a massive
re-write. With the KDE trading service and the OpenParts model,
components are known by their properties. This means that changing
the image viewer component is as easy as registering the new
component with the proper properties. No recompiling or recoding is
necessary.
A lot of components don’t need the graphical functionality that
OpenParts provides. Often, the KOM layer or even straight CORBA is
enough. An example of this is the Internet dialer component. Any
application that wants or needs to connect to the Internet via a
dial-up connection can do so using this component. They access it
by requesting a dialer with certain properties from the trader.
Note that this means that no one application is tied to being The
Internet dialer. The current implementation uses KPPP, the KDE
modem dialer, to do the dialing, but it doesn’t have to. The actual
method of dialing is irrelevant to the application using this
component — they just want the resulting connection.
KOffice Suite
The KOffice application suite is possibly the closest thing to a
“killer app” that KDE has yet produced. It is a full-featured
office application suite (including a word processor, spreadsheet,
presentation manager, illustrator, charting tool, and more) built
on the KOM/OP component technology. This makes it the first Unix
office suite (commercial or free) to support embedded application
technology.
The individual KOffice applications are fully functional even as
stand-alone apps. KWord is a “frame-based” word processor in the
vein of FrameMaker. This makes it acceptable for use as a desktop
publishing app, in addition to it’s complete word processing
abilities. KSpread extends its already large collection of built-in
mathematical functions with Python scripting support. Users can
construct arbitrarily complex KSpread documents in a manner similar
to VBA-enabled Excel documents. There is little that PowerPoint
does that KPresenter cannot do.
Even with all of this individual functionality, the true power
of KOffice can only be realized with its integration as a whole.
Because all KOffice applications are built on KOM/OP technology,
each app can be used as an OpenPart. That is, it is possible to
“embed” a document from one KOffice part into another.
For example, say a user is working on a KWord document when she
realizes that a table with a spreadsheet and chart in it would add
a little visual punch. She can do this by importing an entire
KSpread spreadsheet and KDiagramm chart. This isn’t a static
cut-n-paste, though, an actual KSpread document is embedded into
the document.
This means that the user can dynamically manipulate the
spreadsheet and chart without leaving the KWord document. Clicking
on the spreadsheet causes the KWord menus and toolbars to be
replaced with the KSpread versions. Clicking outside of the
spreadsheet restores the originals. From the point of view of the
user, all parts of the document are all integrated fully inside
that document. They no longer appear to be separate parts from
separate applications.
A much more detailed look at the KOffice suite can be found at
http://www.mieterra.com/article/koffice.html
Look (and Feel) At Me
Now
Some of the changes in KDE 2.0 involve “look and feel” issues. The
current KDE is already quite configurable in that regard. What will
change is the level at which changes can be made. Instead of
individual, disconnected changes, the user will be able to modify
nearly every aspect of KDE look and feel in a consistent and
high-level manner.
“Themes”
The KDE window manager (kwm) has supported basic “themes” for quite
some time. Likewise, it has been possible to change color schemes
and key-bindings for all of the desktop almost since the beginning.
All that said, KDE will have a drastic overhaul with respect to its
theming capabilities for 2.0.
The first and most obvious change will be the ability to
customize the look of each individual widget. The current widget
styles of Windows9x and Motif will join NeXT, MacOS, Java Metal,
and every other possible style one could imagine. Likely, there
will also be many styles that aren’t quite imaginable yet! The
ability to customize the look, size, and actions of each and every
widget is nearly total.
These widget styles will be included in “pluggable” libraries
that can be distributed in binary or source form. To change to a
different style, one would simply have to drop in the correct
library, go to the theme/style manager and their desktop will
assume an entirely new look. It will not be required to recompile
anything to use a new look — all styles are dynamically loaded at
runtime. This is true “plug-n-play” theming.
On a technical level, these styles are not pixmap based. That
is, the underlying graphics system does not need to use pictures
for all of the widgets. This approach is very slow on even high end
machines. The KDE/Qt approach uses virtual functions for all of the
widget drawing. The result of this is widget drawing at nearly the
same speed as the “original” or default style (the actual speed
depends on the complexity of the drawing). Note that pixmaps may be
used if so desired — the theme engine just does not depend on
it.
The themes will go beyond widget styles, however. All visual
aspects of the desktop will be controlled from one central
location. Say a user wants their desktop to look as close as
possible to a Macintosh. One click in the theme/style manager will
cause the widgets and color scheme to have the Platinum style. The
icons will be replaced with “Mac-like” icons. The window borders
will also change to look like a Mac. If that weren’t enough, the
key-bindings would also change to be comfortable to a Mac
addict.
Most of these changes are already possible to accomplish with
the present tools. What is lacking now, however, is an integrated
and central way of managing all of this. The future theme/style
manager will allow the user to customize everything with only a few
clicks of the mouse.
More KDE-Aware Apps
This is the most “evolutionary” of all of the changes. As each day
progresses, it seems that there is an increasing number of KDE
apps. This pace will continue or even increase as time goes on.
Probably the biggest segment of new applications will be
applications that traditionally are found only in the Windows/MacOS
world. These applications will be either “clones” of popular
Windows apps or applications that have never been thought of
before.
A growing number of “third-party” or commercial applications
will be “KDE aware” without being fully integrated into KDE. The
StarDivision StarOffice suite already does something similar with
its recognition of the KDE mime-types, KDE drag-n-drop and an
awareness of the panel. This trend can only continue.
Many legacy X and even console-based applications will also get
fresh KDE wrappers around their older interfaces. This will happen
either by taking the “work” part of the code from an application
and putting a KDE GUI on the front of it or by grafting a CORBA
wrapper around it. This latter approach will be used most often for
console-based utilities that have command-line interfaces. A CORBA
wrapper will be put “around” this utility, making it into a server.
Any KDE app will then be able to access that utility’s
functionality in a manner consistent with all other CORBA apps.
Playing the Politics
Game
Some of the changes to KDE can best be described as “political”
changes. These are changes that don’t really affect KDE developers
and current KDE users very much. Yet these changes will have an
impact on the way that KDE is used and perceived by non-KDE
users.
“Open Source” Qt
Undoubtedly the biggest impediment to complete acceptance of KDE
was the perceived limitations to the Qt license. In fact, the GNOME
project started as a direct consequence of this lack of “true
freeness”. This is all in the past as of Qt 2.0. The newest version
of Qt is covered under the QPL, which has been “certified” as an
Open Source license by the Open Source Initiative (OSI) and the
founders of the Debian Free Software Guidelines.
The effect of this is nearly entirely political. Those users
that did not use KDE solely because of Qt’s license may now use the
system with no problems as to it’s freeness.
GNOME Acceptance
Much of the changes in KDE 2.0 will be related to “choice” — the
user will simply have more choice in how their desktop will work.
This idea is extended to those users that may want to use some
GNOME applications. If they wish to do so, KDE will not only not
get in the way, but will make sure that the transition is as
seamless as is reasonably possible.
This starts with “cross-theming.” The GNOME/Gtk+ method of
handling widget styles is currently done with pixmap “rendering
engines”. The KDE theme manager will automatically detect the
configuration files for GNOME apps and modify them in such a way as
to create an as close as possible approximate of the current Qt
style. Other “theme” components such as key-bindings will also be
approximated on the GNOME side.
The drag-n-drop protocol shared by the two environments will
also be standardized. That means that files “dragged” from, say,
the KDE file manager can be “dropped” into a GNOME application with
no problems.
Interaction between KDE and GNOME applications will also be much
improved. The higher-level CORBA protocols will either be
standardized or wrappers will provide an illusion of
standardization.
As a general rule of thumb, the standard user should not be able
to find any significant differences between a KDE and a GNOME app
while running the KDE environment.
Kurt Granroth is a software engineer with the
Motorola Satellite Communications Group in Phoenix, AZ. He holds a
B.S. in Computer Science and Secondary Education from Michigan
Technological University. Kurt is a recent member of the KDE Team
and is responsible for KBiff, KAppTemplate, numerous hacks in the
KDE libraries, and overall KDE evangelism.