Next Previous Contents

7. The draft

7.1 Introduction

This document, currently only a work draft, attempts to define a generally acceptable way of implementing themes for KDE.

We are seeing a theme as a set of characteristics (visual and functional) which represent for a user the way in which he expects his desktop environment have to respond to its needs.

As already stated, the desktop's characteristics which define a theme are grouped in: visual (color schemes, icon sets, root window images, window manager decorations, fonts, a.o.) and functional (keybindings, mouse button bindings, desktop elements' positions, window manager's functionalities, a.o.).

Hopefully, this document will slowly evolve to a basic documentation for the future global theme implementation. Right now, we'd like to use it as a start base for further discussions and as a framework setting.

7.2 Purpose

In our world (we mean in our ``computing'' world) people like to have the freedom of configuring things. Many like this freedom so much that sometimes they even forget to get the real work done and they just keep configuring all the time :-). Others love to have things configurable, but they aren't necessarily willing to do all the configurations by themselves. The later like sometimes just to take a valid (and pleasant) configuration from a friend and use it.

On this background, the Unix's world configuration themes were born. We think nobody could really say when this concept firstly appeared, but most notable examples of theme implementations should be considered fvwm, afterstep, WindowMaker and Enlightement window managers.

With KDE's way to do, we hope to provide a simple and fast way for configuring our desktops for our functional needs and visual pleasure.

7.3 What themes should do ...

Most important, a themes implementation will have to offer (with the aid of a simple to use interface) the possibility to easily unpack, apply, store, pack and handle all the ressources involved in the definition of a theme. This interface will be named further in this document a theme manager.

An easy way to generate themes have also to be provided.

Visual ressources. A complete list of the ones to be handled by the theme manager follows:

* color schemes;

* icons - a minimum set of mandatory icons have to be defined, for example: trash icon, folders icons, executable icon, text icon a.o.;

* toolbar icons - a minimum set has to be defined;

* windows' decorations :

* titlebar buttons pixmaps;

* titlebar pixmap;

* border pixmaps;

* root window pixmaps;

* fonts;

* widgets' background pixmaps;

* sounds set;

* screensaver configurations;

Functional ressources. A complete list of the ones to be handled by the theme manager follows:

* window manager functionalities (all presently included in kcmkwm);

* xset defined functionalities (keyboard, mouse, screen blanker etc.);

* desktop elements positions and functioning (panel, taskbar, wm modules, virtual desktops)

* sound events; * functionalities specific to diverse applications (system monitors, mailbox monitors etc.);

7.4 ... and what shouldn't

It is our central point to make sure KDE will ever function perfectly (as it does now :-) without any themes implementation. Our goal is to make themes place themselves over the whole configuration structure owned by a KDE user and transparently add the needed functionality. But if the user would ever choose to take themes out of his desktop environment (why should he?:-), KDE must function without themes as correctly as with them.

The implementation of themes should be done in such a way so any other KDE application shouldn't need to be modified to comply with themes. The members of the KDE themes have however agreed to try to contact authors of other applications in order to kindly discuss about possible inadvertences or inflexible implementations in these respective applications, especially when an eventual better solution will also help the themes project.

The themes manager will never be turned in a session manager or any other sort of active element of the desktop. The user should be able to simply not install theme manager at all.

The system's ressources usage by the theme implementation have to be very low. A color quantizer for icons and eventually a compressing storage method (for graphics and media files) should be included.

7.5 Technical details

The way in which KDE manages presently its visual and functional ressource makes the task of creating a theme implementation not too difficult. A theme manager application will only have to deal with the present standard filesystem structure and with the present ressource configuration (rc) files.

The themes manager have to be able to package all the needed ressources in a single shell archive or tape archive or rpm file (or any other packaging concept will be found convenient).

In order to reduce the a filesystem overload, the theme manager will be able to handle inheritance. Ressources from a given theme will be usable by any other inheriting theme.


Next Previous Contents