Linux Today: Linux News On Internet Time.
Search Linux Today
Linux News Sections:  Developer -  High Performance -  Infrastructure -  IT Management -  Security -  Storage -
Linux Today Navigation
LT Home
Link to Us
Linux Jobs

Top White Papers

More on LinuxToday

The KDE Future

May 26, 1999, 08:48 (195 Talkback[s])
(Other stories by Kurt Granroth)

By Kurt Granroth

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/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

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.

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.