KDE: The Korporate Desktop Environment

A future where Linux PCs are the rule rather than the exception depends largely on Linux succeeding in the workplace. To do that, Linux has to be usable by John in Sales and Jane in Finance. KDE puts that friendly face on Linux. If you're ready to switch your entire office to open source, KDE can bootstrap your efforts. Here's how.

Today, whether or not Open Source development can produce complex and useful software is no longer at issue: that question has been answered resoundingly, “yes,” by the sophistication, capabilities, and widespread deployment of Linux. However, the parity and power of Linux has been experienced mostly in the server room. In a way, that makes sense: the efforts to build Linux as an alternative server operating system spans a decade, while work on modern desktop environments for Linux has only truly matured within the last two years.

But youth isn’t the only reason Linux hasn’t made a big splash on the desktop. Until recently, pre-loaded Linux desktops were fairly exotic. The average desktop user also tends to be less technically sophisticated than the average server administrator, and Linux has a history of being a technically demanding system.

Moreover, companies think with their checkbooks, and the economic benefits of a Linux-based desktop system are not as easily or as immediately felt as the benefits of a Linux server. It’s little wonder that desktop usage of Linux has lagged considerably behind server deployments.

Fortunately, the prospects for Linux on the desktop are changing. Increasingly draconian licensing agreements, expensive software, and security nightmares are pushing users toward Linux. It also doesn’t hurt that Linux has become highly respected, with IBM, Oracle, and HP (among others) building significant businesses on the shoulders of Tux. Most importantly, sophisticated desktop software is now available for Linux.

KDE, the K Desktop Environment, version 3 (http://www.kde.org) is a cutting-edge desktop platform that’s useful for both the average and sophisticated user. It’s easy to use, robust, and full of features. Yes, it has cool icons, menus, and whiz-bang graphics. But, it also has a set of core features — namely, central configuration and resource sharing — that make it ideal for office use. If you want to switch your entire office — from server farm to front desk — to open source, KDE’s common desktop features can bootstrap your effort.

KDE: Konquer the Desktop Effortlessly

While you might be familiar with installing KDE on a single system, you may have more limited experience deploying it in multi-system environments. In environments like an office, or a corporate or university department, you have three options for widespread installation:

  1. You can treat each system individually, and install an entire KDE system on each desktop. While this approach appears to be simple and direct (after all, it leverages what you already know how to do), it does little to lower costs and improve utility. In particular, each system is independent and has to receive individual attention when you want to modify the configuration or when something goes wrong.

  2. You can install KDE on a central server, and let users run all of the KDE applications from there. Since KDE is based on X, you can run KDE applications remotely, leveraging the computing horsepower of your server, and saving money on each desktop. This approach is often referred to as a “thin client” solution, reflecting the modest demands placed on each desktop system. (Designing and implementing a thin client solution is outside of the scope of this article, but there are some excellent online resources that cover the topic in depth. One such resource is the Linux Terminal Server site at http://www.ltsp.org.) There are two disadvantages to the thin client approach: it takes little advantage of the powerful processors found in modern desktop systems, and it may place an undue burden on network resources.

  3. Like the first approach, you can install KDE on each desktop, but share (using a file server and something like NFS) common resources (like KDE configuration and application data files) between all users. While this configuration is a little more complicated to establish, using shared, centralized resources can help lower support and training costs, and makes collaboration and information sharing easier. It also utilizes existing resources more optimally.

KDE can be deployed using any of these methods, but the latter approach is probably best if you’re trying to push desktop Linux out to a number of users. Let’s see how to deploy and share KDE resources from a central server, and how to create a standard corporate desktop that can be customized only to the extent that you allow.

In The Middle of Everywhere

Before we create our corporate KDE environment, let’s get our bearings. Our sample network will consist of one administration system (admin), a file server (fileserv), and any number of desktops (desktop1, desktop2, etc.). We’ll assume that fileserv is running NFS to share files, and that admin and all of the desktops can mount NFS shares from fileserv. Our goal is to place a set of KDE configuration files on fileserv, and then supplant each desktop’s independent set of KDE configuration file with one set of shared files.


To begin, we install KDE on admin. The easiest, quickest and most fool-proof way to install KDE is to use pre-built binaries. Most Linux distributions come with easy-to-install KDE packages, though KDE binary and source packages can also be downloaded directly from KDE’s file servers at http://downloads.kde.org. The latest stable release can be found in the /pub/kde/stable/latest directory on that server.

If you choose to install the KDE packages by hand (as opposed to using a helper tool such as apt-get that handles dependencies and installation order for you), remember to first install arts (the KDE media system ), then kdelibs, and then kdebase. After those base packages are installed, the rest of the KDE packages can be installed in any order.

Upon completion of the install process, all of the KDE files will be found under a single directory in the file system, which we’ll refer to as $KDEPREFIX. When installing binary packages, $KDEPREFIX is often /opt/kde or /usr. When compiling from sources, $KDEPREFIX is /usr/local/kde (this default can be changed by passing a different path to configure using the –prefix option).

For this article, we’ll assume that $KDEPREFIX is /opt/kde. If KDE is installed elsewhere on your system, simply replace /opt/kde in our examples with your $KDEPREFIX.

If you look at the contents of $KDEPREFIX, you should see something similar to the following:

# ls -AF /opt/kde
bin/ doc/ etc/ include/
lib/ man/ sbin/ share/

Of these directories, the one we’re most interested in is share, since it’s the place where KDE stores default application data and configuration files. A quick peak in the share directory reveals places for configurations (share/config), data (share/apps), icons (share/icons), wallpaper (share/wallpapers), and more.


Once KDE has been installed on admin, our next task is to copy the /opt/kde/share directory (and all of its contents and subdirectories) from admin to a shared file system hosted by fileserv. Using the admin machine, copy /opt/kde/share to any file system that can also be remotely mounted by admin and the desktops, such as NFS and SMB shares.

For example, if /shareda is a widely-accessible NFS file system on fileserv, and it’s mounted locally on admin as /remote/shareda, you would do something like this to perform the copy:

# cp -pr /opt/kde/share/remote/shareda/kde-share

With the share directory now on the file server (it’s at fileserv:/shareda/kde-share), we are ready to create and configure a standard desktop. But first, let’s review how KDE finds and uses application data and configurations.


For flexibility, KDE resources can be stored anywhere on your computer. To find those resources, KDE uses a set of paths, some pre-defined, and some stored in the KDEDIRS and KDEHOME environment variables. KDE applications use these paths to save their settings and find their data.

By default, /opt/kde, the directory where KDE is installed, is automatically added to KDEDIRS. Additionally, any number of supplemental KDE directories can be added by setting KDEDIRS appropriately.

For example, if you decide to store KDE application data on a pair of NFS partitions mounted at /mnt/nfs1 and /mnt/nfs2, it would be a simple matter to search those directories by adding the following to the user’s environment:

export KDEDIRS

Given that setting, KDE applications will search for settings and data in both of the NFS partitions as well as the default /opt/kde directory. Of course, users are rarely given write privileges to shared system directories, so KDE provides the concept of “home” directories used to store the user’s personal configuration and data files.

The default user path is set to ~/.kde, but this value can be changed to any arbitrary location by setting the KDEHOME environment variable. As with KDEDIRS, multiple paths can be defined in the KDEHOME variable (just separate the individual paths with a colon), allowing for maximum flexibility.

KDE uses the configuration directories to implement a cascading configuration system. When a KDE application reads a configuration setting, the installation directory is searched first, followed by a search in the directories defined in KDEDIRS. Finally, the directories defined in the KDEHOME variable are searched. In case of conflicts, the last value read is the setting that is actually used.

The exact order in which the default, KDEDIRS, and KDEHOME directories are searched can be seen by running kde-config with the -path config option. For example, the configuration directories known to KDE on the admin computer can be seen with the following command:

# /opt/kde3/bin/kde-config -path config

Here, root’s KDEHOME directory, and the default installation directory, /opt/kde are listed. (It’s important to note that the directories shown by kde-config -path config are listed in precedence order. That is to say, settings found in files in KDEHOME have higher precedence than those found in KDEDIRS; in turn, settings in KDEDIRS have higher precedence than those found in /opt/kde. Also note that precedence order is always the reverse of scan order.)

Ready to Customize

With that background in mind, let’s change KDEHOME on admin to be /remote/shareda/kde-share by putting the following into our .profile (or, if you use another shell, into its start up file):

export KDEHOME

By changing KDEHOME to the shared directory, any changes we make in the KDE Control Center or in any KDE application on the administration system are automatically saved to the network mounted share directory. This can be easily confirmed by running kde-config again:

# /opt/kde3/bin/kde-config -path config

Using admin, tinker with KDE to configure your desktop as you want it to appear for all of your users. Then, when you’re ready to deploy your standard desktop, install KDE on each desktop, and use NFS to mount fileserv:/shareda/kde-share on /opt/kde/share on every user’s machine. This latter step supplants each user’s local KDE configuration files with your “corporate standard” configuration.

Settings in ~/.kde will override any settings found in the NFS mounted directories. This allows you to define system-wide defaults and allow individual users to create their own customsettings. And, as we’ll see in the next section, you can greatly limit what they can customize, too.

With your administration system set up, any changes you make from now on in the KDE Control Center or in any KDE application are mirrored on all of the desktop systems.

Obviously we won’t want to use our administration system as a day-to-day desktop, at least not with KDEHOME set as it is. A pratical option is to set root’s environment so it can be used for KDE administration. Logging in as a regular, unprivileged user allows the administration system to be used as a regular desktop. In larger environments, you may also want to use a revision control system, such as CVS, to store the configuration files.

Maintaining the Status Quo

Allowing users to override system settings is not always desirable. To keep administration headaches to a minimum, many corporate IT departments define a standard system configuration, and lock down systems so users can’t alter set policies. Traditional UNIX-style file permissions are one tool for locking down a Linux desktop, but support is still required from the applications to prevent users from affecting and using local configurations.

KDE provides support for policy-controlled configurations via the KDE kiosk framework, which debuted in KDE 3.0. Work on the kiosk framework was originally inspired by the requirements of public access terminals, where locking down the system is mandatory. While adapting KDE for kiosks, it was quickly realized that the very same framework was perfectly suited for managing systems in a corporate environment.

The KDE kiosk framework currently provides three types of restrictions. The first type of restriction is probably the most obvious: application settings cannot be changed. The second type of restriction changes the behavior of applications: you can prevent a user from using a specific feature in a specific application. And the final restriction prohibits users from changing the settings of an entire class of resources. For example, you can configure KDE so that no one can change any icon resource in any setting in any application.

Let’s look at how to use each type of restriction to create and maintain your standard desktop.

Locking Down Application Settings

Using the KDE kiosk system, you can lock down individual settings, groups of settings, or entire applications. This is done by editing a system wide configuration file and marking settings as unchangeable (or immutable in KDE lingo).

KDE configuration files consist of groups of key=value pairs, where each group of configuration options starts with a title enclosed in square brackets, such as [This Is A Group Title]. The following example was taken directly from a KDE configuration file:


As the system administrator, you may not want users to alter some these settings. For example, to lock down the ShowFileTips setting, while allowing a user to modify other settings, simply to add [$i] after ShowFileTips:


The [$i] makes ShowFileTips immutable. To lock down the entire [FMSettings] group we would specify something similar after [FMSettings], like so:


To lock down all of the settings in the file, you could preface the file with [$i] on a line by itself:


In an office, many users will be sharing such locked-down configurations. However, some flexibility is required to reflect each user’s particular environment. For example, each user has his or her own home directory. KDE provides for per-user customization by allowing environment variables and even shell commands to be used in configuration files.

For example, if the value of the CORPNEWS environment variable should be used as the Konqueror “Home” URL instead of “~“, you could edit the HomeURL entry this way:


Note the [$e] following the HomeURL key. This signifies that the setting contains a dynamic value. It can also be combined with the immutable flag to prevent the user from changing the setting.

As of 3.1, KDE allows not only environment variables, but shell commands to be used in place of literal values. To have the user’s home URL defined by a program, the appropriate command can be placed directly in the configuration file:


Note the use of parentheses. This denotes that the entry is a shell command rather than an environment variable. To lock this particular configuration down, we would write:


In our office configuration, we want to define and lock down several desktop settings, starting with the default panel configuration. To achieve this, we’ll set up the panel exactly how we want it using Panel configuration in the KDE Control Center, and then edit and “lock” the configuration file.

Use your favorite text editor to open the Panel configuration file, which in this case is /opt/kde/share/config/kickerrc (since the name of the panel program in KDE is “kicker”). Add a [$i] to the very top of the file before any settings, and save it. Now all the desktops will have the same panel setting, and the users will not be able to change it. The people at the help desk will love you!

To control the various look and feel options available in KDE, including such things as icons, wallpaper, color schemes, and widget style, use the KDE Control Center to design your official corporate look and feel, and then edit the /opt/kde/share/config/kdeglobals file. You don’t need to lock down the entire file, just control a few of the settings.

For example, to set the background wallpaper, open /opt/ kde/share/config/kdesktorc and mark the Desktop0 group as immutable:


For more information on customizing the look and feel of KDE, see “The Famous Five”.

The Famous Five – Part 1

KDE is one of the most customizable desktops available. While customization may not be as important in the office as other KDE features, a discussion of KDE would be remiss if it didn’t touch at least briefly on this hallmark feature. There are five primary “look and feel” categories in KDE, the so-called “Famous Five.”

1. Widgets

Interface elements such as buttons, menus, and scroll bars are referred to as widgets. The look, feel, and even behavior of the widgets can be changed substantially by selecting different widget styles. The Style control panel allows you to select a widget style, as well as choose from various effects such as menu transparency and widget animations. There is even a live preview of the selected style that makes picking the perfect style that much easier.

Some styles, such as “Lite” and “dotNot,” opt for a simple minimalistic look. Others deliver whiz-bang looks and stunning dynamic effects. Great examples of such fancy styles include Mosfet’s famous “Liquid” style, as well as the beautiful “Keramik” style that is new in KDE 3.1.

Most KDE widget styles are C++ plugins. This allows for great flexibility and some stunning effects. The actual plugins can be found in the $KDEPREFIX/lib/kde3/plugins/styles directory. While many styles are available in binary form or come with KDE, building styles that you download is quite simple:

% tar zxf hotNewStyle.tar.gz
% cd hotNewStyle
% ./configure –prefix=`kde-config –prefix` &&
make && make install

2. Window Decorations

The title bar and borders around windows are called window decorations. The look and behavior of window decorations can be customized in the Window Decorations control panel. In addition to picking a specific look, the order of the window buttons (close, minimize, etc.) can also be controlled from this panel.

Window decorations come in several formats. Many are C++ plugins while some are pixmap-based. KDE even supports icewm themes’. The more advanced KDE decorations often exhibit interesting and unique behavior. For instance, the “BII” decoration provides BeOS-style tabs on the windows that can be moved by clicking on them while holding the SHIFT key and dragging the mouse. The “Glow” decoration features animated buttons.

3. Colors

Depending on your personal preferences, environment, and widget style, the right color scheme can make all the difference in the world. The colors used by KDE widgets and window decorations are defined in the Colors control panel. Several predefined color schemes come with KDE, and users can create their own custom schemes. These color schemes can be shared with others as KDE color scheme (.kcsrc) files. Custom schemes are saved by default to $KDEHOME/share/apps/kdisplay/color-schemes.

4. Fonts

Fonts have long been a thorny issue for Linux desktops. However, with the addition of antialiasing and improved scalable fonts to XFree86, things have improved considerably in recent times. KDE continues to integrate these enhancements.

A recent addition to KDE is the Font Installer control panel. This panel allows easy installation and management of fonts on a KDE system. You can set which fonts are used by default in KDE applications in the Fonts control panel. The Fonts control panel also controls font antialiasing settings, including subpixel hinting.

5. Icons

For many people, being able to alter the widgets, windows, colors, and fonts is enough flexibility. But it wasn’t enough for the KDE artists and developers who introduced the concept of icon themes. Icon themes allow users to change all of the icons used by KDE applications with a single click of a button. KDE ships with no less than five icon themes of varying styles and color depths.

To change icon themes, go to the Icons control panel and pick from the list of themes available. If you have downloaded a new theme, you can add it by clicking on “Install New Theme…” and choosing the new theme you just downloaded. Icon themes are usually distributed as tarballs, but you don’t need to decompress a theme to use it. The Icons panel does the work for you.

Icon themes can be found in the share/icons/ subdirectory, as well as the $KDEDIRS and $KDEHOME directories. Each theme comes with an index.desktop file that describes the contents of the theme. Themes can also “inherit” from another theme. This allows a theme to be distributed with just a few specific icons; missing icons are supplied from the inherited theme. This makes it much easier to create and distribute icon themes without having to create replacements for each of the 1,800 icons in the default icon set.

In addition to different sets of icons, the Icons control panel allows you to assign dynamic coloring effects to differentiate icons in their normal, active, and disabled states, as well as to set the default sizes used. This allows for some stunning effects such as grey icons that bloom into full color when the mouse is passed over them. The Icons control panel also controls icon animations (that were added to KDE 3.0).

There are dozens of nooks and crannies around the KDE desktop that you can customize. From desktop backgrounds to application launch feedback to MacOS-style menubars to the fonts and colors used in the filemanager, you can make KDE look just about any way you want to. This wealth of options has resulted in a thriving community of artists that have generated a wealth of backgrounds, themes, styles, and add-ons for KDE users to choose from.

Figure Two: A new look for KDE

Some of these exciting new look options are set to arrive with KDE 3.1, including the “Keramik” widgets and a new set of “crystal” icons. This new look can be seen in Figure Two, as it appeared in KDE’s development tree at the time of this writing.

Also, be sure to install the kdeartwork package to get more icons, wallpapers, screensavers, window decorations and widget styles!

For even more KDE eye-candy visit KDE Look, the authoritative on-line resource for KDE add-ons, at http://www.kde-look.org.

Finally, to provide default settings for sending and receiving email, configure KMail on admin to your liking, and edit /opt/kde/share/config/kmailrc. A snippet of a sample kmailrc is shown in Listing One.

Listing One: A sample shared KMail configuration file

Default Identity[$i]=0

[Identity #0]
Email Address[$i]=$USERMAIL
Organization[$i]=Acme Inc.
Reply-To Address[$e]=$USERMAIL

Note that we didn’t lock down the entire Identity group. This allows the user to still set things such as their signature.

Tightening the Bolts a Little Bit More

While locking down configuration files is quite useful, KDE has a few more tricks to show you. As mentioned above, KDE lets you disable specific actions in KDE applications. Actions include such things as saving files, reporting bugs, and changing toolbar settings. These restrictions are recorded in the share/config/kdeglobals file in a special group called [KDE Action Restrictions].

A list of common actions that can be restricted can be found in the share/config/ui/ui_standards.rc file that is shipped with KDE. Additional application specific actions can be discovered using the dcop (Desktop COmmunication Protocol) scripting tools. For instance, to find all the actions used by KMail, start KMail, and then run the following command:

# dcop kmail qt objects | grep KActionCollection/ | cut -d ‘/’ -f 3

By prefacing these actions with action/ and placing them in a KDEGlobals file, you can enable and disable actions at will. In addition to individual actions, there are also action groups, as listed in Table One.

Table One: Restrictable Action Groups

Action NameDescription


Defines whether the –config command line option should be honored. The –config command line option can be used to circumvent locked-down configuration files.


Defines whether the user will be able to lock the screen.


Defines whether the user will be able to logout from KDE.


Defines whether toolbars may be moved around by the user.


Defines whether or not the “Run Command” (keyboard shortcut ALT-F2) option is available.


Defines whether users may execute desktop files that are not part of the default desktop, KDE \ menu or registered services. The default desktop includes the files under $KDEDIR/ share/kdesktop/Desktop but not the files under $HOME/Desktop. The KDE menu includes all files under $KDEDIR/share/applnk. Registered services includes all files under $KDEDIR/share/services.


Defines whether a shell suitable for entering arbitrary commands may be started. This also determines whether the “Run Command” option (ALT-F2) accepts shell-commands or not

As an example, if you want to prevent users in your office from changing keyboard shortcuts, seeing “About KDE” dialogs, using shell commands from KDE applications, and overriding icons we would add the following to the /opt/kde/share/config/kdeglobals file:

[KDE Action Restrictions][$i]

Note the use of [$i] immutable flag to prevent users from overriding these restrictions in their own kdeglobals file.

Locking Down Resource Types

As a final flourish, individual resource types can be restricted. This effectively prevents users from overriding system defaults (such as icons) with their own files in $KDEHOME. Any of the resource directories listed in Table Two can be restricted in this manner.

Table Two: Resource Directories



All resources




Configuration files


Application data


Data files for <appname>


Program files


HTML documentation






Localization files


Mime type definitions



Protocol and filter definitions


Component definitions


Sound files





Using Centralized Information Resources

Restricting access to resources is important, but so is defining which resources should be shared. It’s common to find LDAP address books, proxy servers, and even public key infrastructures in the modern office. KDE not only supports a variety of such shared resources, but also allows users and administrators to easily define such resources in a central configuration panel or file. Once defined, shared resources become accessable to all KDE applications.

One example is the KDE address book, which is shared by all KDE applications. The address book itself uses the industry standard VCARD format. To establish an office-wide address book, open the “Address Book Configuration” panel in the KDE Control Center, click on the “Add…” button, and add the resources you want to share.

There are currently four possible resource types: a flat text file, a directory containing one file per contact, an SQL database, or an LDAP server. (Some of these resource types may or may not be available depending on the options used to compile KDE.) Figure One shows the KDE panel for configuring LDAP servers.

kab ldap
Figure One: Setting KAddressbook to use an ldap resource

Once a resource has been added, it appears in the list of available resources. The resource can then be activated by simply checking the box next to its name. A resource can be set as the default resource by clicking on its entry in the resource list and then selecting “Use As Standard”.

Once you’ve chosen the resources, lock down the /opt/ kde/share/config/ kabcrc file using the KDE kiosk framework. Setting up and maintaining proxy servers for tasks such as web browsing is similarly easy.

This really only scratches the surface when it comes to defining and using centralized resources in KDE. Within the KDE Control Center you can find panels to set up Windows file shares, manage local and remote printers, and set up network resource discovery services.

This broad array of tools and infrastructure support enables KDE to be easily and seamlessly integrated into existing corporate networks.

In addition to infrastructure, KDE ships with an impressive array of applications that you can also standardize on, including KOffice (an office productivity suite), KMail (an email client), Konqueror (a robust Web browser), and others.

KDE: Kan Do Everything

Today the question isn’t if the Linux desktop will take off, but where the first significant inroads will be made. The answer to that question most likely lies within the offices of small, medium and large businesses. The flexibility, stability, security, and cost of desktop systems are of much greater concern in the corporation than in the home. Moreover, companies are already adopting Linux and have the means (that most home users lack) to support new system deployments : a trained IT staff.

It’s evident that the spread of free software from the server room to the desktop requires that projects such as KDE, XFree86, and Linux continue to flourish and keep their focus. Doing that requires the continued support of a community of developers, artists, documentors, translators, sponsors, and users.

But, if the future is anything like the past, then desktop Linux has a rosey future indeed.

Aaron J. Seigo is a KDE developer living in Calgary, Alberta. He can be reached at aseigo@olympusproject.org.

Comments are closed.