Improved window themes with deKorator 0.5

If you love to customize the appearance of your KDE Desktop, then you probably already know deKorator, a pixmap window decoration engine initially written by Moty Rahamim for KDE 3.

When I ported it to KDE 4, I did not try to improve it in any way; my first goal was to have it available at all. The only new feature in deKorator 0.4 was support for transparent themes to make use of the ARGB ability of KWin 4.3.

Today, deKorator version 0.5.1 has been released, and it comes packed with a whole lot of new features and bug fixes. I was too lazy to update the ChangeLog file (you can get the svn log from playground/artwork/dekorator, though), but since the changes need to be documented somewhere for theme writers, I decided to write a small “changeblog”.

Improved theme installation and selection

The most often reported bug required a rewrite of the theme selection dialog.

deKorator new theme selection dialog
The new theme selection dialog shows previews of the themes

When you installed a theme and clicked on it in the list, it was not selected as the current theme, but you had to “apply paths” first. The feature to set individual paths has been removed from the dialog; simply clicking on a theme selects the paths automatically (you can still set them in the config file manually).

Improved detection of theme files

Another problem was that installation of themes often failed because of the strict naming requirements. Now the detection is much better, it even detects old deKorator 0.1 themes, and tries to find decoration archives inside the installed archive. Some themes still do not install correctly because of wired bugs in the theme files. For example, there are themes that have the “deco” and “buttons” directories directly in the root of the archive, without any directory for the theme name …

GetHotNewStuff support

For many themes, installation can now be done directly from the KNewStuff interface to the site “”, where over 150 deKorator themes can be downloaded.

deKorator KNewStuff download dialog
Download and rate deKorator themes using the GHNS dialog

Thanks to improvements in the coming KDE SC 4.5 release, you will even be able to rate themes or upload your own themes. With that, we come to a feature that will be appreciated by theme creators.

Separate images for inactive windows

User “Shirakawasuna” requested a set of different images for buttons on inactive windows, and later suggested to use Emerald compatible button files. This has now be implemented in deKorator 0.5.1.

deKorator buttons image file from Emerald themes
A single image contains all button states
(the chessboard pattern shows transparency)

Inside the “buttons” directory, there are usually the directories “normal”, “hover”, and “press”, but you can now also place a single file for each button type directly inside the “buttons” directory. The file has to be named “buttons<Type>.png”, where <Type> is “Close”, “Max”, “Min”, “Restore”, etc. as before.





Contents of deKorator theme archive “Example-theme.tar.gz”

This file must have six images in a single row, all equally sized. The order is “normal”, “hover”, “press” for active windows, then “normal”, “hover”, “press” for inactive windows. For compatibility, you should keep the old individual button files until the new version has been adopted by users.

Note: When porting Emerald themes, you have to rename the files, e.g. from “buttons.max.png” to “buttonsMax.png”. You might also need to add some transparent padding to get them aligned correctly within the frame, as deKorator always centers images that are smaller than the frame.

Additionally, you can now also supply separate images for the frame of inactive windows.

Example of separate decoration images
deKorator supports separate decoration images for active and inactive windows

Inside the “deco” directory, you can place a directory named “inactive” with the same file layout. You do not need to add all images; those that are not provided are used from the “deco” directory.

Attention! Use this feature with care!

deKorator has been designed to allow the user to colorize active and inactive window frames by using the respective colors from Systemsettings, so do not provide separate images if you just want different colors. It is intended that this feature is used to make graphics for inactive windows less detailed (for example, by removing stripes or other decorations). Check the “Modern System” or “KDE 2” themes to see what I mean.

I hope that these improvements give theme writers more freedom in their design or porting efforts; I am looking forward to new themes, maybe even some with real alpha transparency.

Bug fixes in deKorator 0.5.1

  • Fix borders on maximized windows (requested by user “Shirakawasuna”)
  • Fix resize region with small borders (thanks to “Shirakawasuna” for reporting the issue, clearly seen on his “Dots” theme)
  • Fix “hand” cursor over buttons (requested by “Shirakawasuna”)
  • Fix possible crash with NoBorder option (reported by “Ace2016”, thanks!)
  • Fix large images being cropped instead of scaled (reported/requested by “Shirakawasuna”, clearly seen on his Reluna-Bluetiful port)
  • Fix stuck windows when shading windows with masks (this was first reported by “Thailandian”, and later “greggel” found out how to trigger it. Thanks to both!)
  • Fix spelling mistake for masks (found by “Shirakawasuna”)
  • Fix wrong button image “StickyDownPress” used instead of “StickyPress” (thanks to user “greggel” for reporting)
  • Fix partial transparency on button backgrounds (that bug was unnoticed, because there are no partially transparent themes yet)

If you find anything else that needs to be improved, please use the bugtracker.

Skulpture 0.2.4 released

Just in time with the KDE SC 4.4 release, I was able to get out another release of Skulpture, my favorite widget style. The list of fixes is quite long again, partly because Qt 4.6 required some adaptions. The most annoying bug, the Tab key handling in Konversation, has finally been fixed. Two other bugs could cause crashes, so you are advised to update.

Source code and packages for all major distributions are available for download from the site. Note that these packages are not official; you should switch to distribution packages once they are available.

Skulpture Demo

“Look at it again!”

Do you want a stable and bug-free KDE Workspace? You certainly do. But before I talk about bugs, let me chat a bit about myself.

Being a math teacher is not easy; your students hate you for that fact alone. And I have a habit that makes them hate me even more: When there is something wrong with their math, I usually do not help immediately. Instead, I keep saying “look at it again!”, not even telling them where their mistake is. Only eventually they give up, and I need to guide them to the correct solution.

Okay, to tell the truth, they fully support my “bad habit”, because they learn a lot this way. A good mixture of reasoning, patience, and pedantism cannot be bad.

Now, why am I telling you all this?

Today, I closed three bug reports about crashes inside KDirWatch, all duplicates of the well known inotify crash bug that is happening since 4.0. The backtraces were, however, a bit different, and so I asked David Faure (our KIO maintainer) what could be the reason for this.

The whole inotify handling in kdelibs is really low level, nothing a casual C++ programmer wants to look at. I did, however, look at the code some months ago, when I had the (self-imposed) mission to resolve all kdelibs crashers (I miserably failed at that, though). There was nothing wrong with the code. I swear, nothing.

Said bug often happens with updates from package managers. I was thinking about some updated libraries having a different binary layout and with all the latest fuzz about inotify bugs in Linux kernel 2.6.31, which could cause folder views to not refresh on changes, I even feared some incompatibility.

So I “looked at it again”. And guess what? The reason for the crash was obvious, David immediately saw another related bug, and we were able to create a patch in just about two hours. After committing that, I looked at the patch, and found a bug that I introduced. Fixed that, committed that. Guess what? I “looked at it again”, and saw my (hopefully) last mistake.

There is one big difference between us KDE developers and my students. We cannot give up and hope someone guides us to our mistakes. We have to “look at it again” (and again).

PS: The fix is probably too late for the 4.4 beta1 release, but let’s hope the bug is gone for good with the beta2 release.

Short KDE Toolbar Texts

If you use text under or alongside your toolbar icons, you might have the desire to change some of the texts to make them shorter, especially if you do not use english language texts. This tutorial describes the steps needed for KDE 4 applications. As an example, the goal is to change the text “Compare Files” to “Diff” in the Dolphin toolbar.

Dolphin toolbar with long icon text

Step 1: Make sure the application uses “appnameui.rc”

Usually if an application allows editing the toolbars, it saves its custom configuration to a file ending in “ui.rc” in the .kde/share/apps/appname/ directory. To find out if an application really uses this file, simply change the toolbar of that application using the “Configure Toolbars …” dialog, and check if said file exists. For Dolphin, the file is .kde/share/apps/dolphin/dolphinui.rc

Note: This step might crash with some applications (bug reports are already filed). The configuration file is usually still saved correctly.

Step 2: Select the action that you want to edit

Change the icon of the toolbar action that you would like to change the text on. This is only required to get the proper “Action” entry generated in the ui.rc file. There is a “Change Icon …” button in the toolbar dialog that opens the icon selector. For this example, I changed the icon for the “Compare Files” action to the “edit-copy” icon.

Dolphin's โ€œConfigure Toolbar ...โ€ dialog

Step 3: Change the ui.rc file using a text editor

Load the ui.rc file in a text editor. It is an XML file. Near the end of the file there is an <ActionProperties> tag. Inside this tag all modified actions appear:

 <ActionProperties scheme="Default">
  <Action icon="edit-copy" name="compare_files"/>

Now delete the “icon” property and replace it with the “iconText” property:

 <ActionProperties scheme="Default">
  <Action iconText="Diff" name="compare_files"/>

Save the file. This will do two things if you restart Dolphin: you get the original icon back, and the icon text is changed from “Compare File” to “Diff”.

Dolphin toolbar with short icon text

Of course a real improvement would be if translators could simply provide two translations for the action texts, but KDE cannot handle it right now without the developer providing two translatable strings in the first place. I am currently investigating a solution for KDE 4.4, that does not add burden to translators or developers, and works with existing applications transparently. If I fail, I will add text customization from the toolbar edit GUI, as shown in the screen shot.

High-DPI aware KDE applications

Qt 4.6 recently gained support for scaling to higher DPI values on Windows and OS X. Nice, but what about us mortal Linux users? Luckily, X11 applications have long been designed to support different DPI values, at least with respect to fonts.

One of my goals for KDE is to make sure that applications work reasonably well with any display resolution. Text, icons, frames, and spacing between elements must be fully scalable for this to work. Below I will write about the current status and future plans.

Font sizes

KDE applications have been designed to adapt to different font sizes, so there should be no major problems with text sizes. I fixed a few places in KDE 4.3 where hardcoded font sizes where used (r965850, r966832, r966845), but some remaining uses may need to be fixed.

To check if an application uses the fonts specified in system settings, you could change them to some insane values. Some applications do not use the default font for widgets, but try to construct it based on the user settings. This may be a problem when customizable widget fonts are supported in the future. With the Skulpture layout visualizer, you can easily spot those widgets; they are rendered with an annoying red background.

Another problem is with style sheets. Applications that use style sheets internally might not react to color or font size changes. With the layout visualizer, those widgets are rendered with a magenta colored background. Regarding colors, applications should of course respect the user defined colors. In the layout visualizer, widgets that do not use the default palette get a light blue background.

KDE Menu with small fonts and icons
KDE Menu with very small text and icon size

Icon sizes

Qt defines multiple icon usage roles, and the platform’s style defines the actual sizes for them. Generally, applications respect these sizes automatically for widgets. KDE adds its own set of icon usage roles, and most applications also respect them. Unfortunately, there are still some applications that request fixed size icons.

Applications that want to use icons next to a single line text label should use the Small icon size; for icons that are to be rendered next to two lines of text, the Large icon size is recommended. Icons that are not used directly related to a text can use one of the other Qt or KDE icon sizes.

For KDE 4.4, I made the size for Dialog icons configurable (r986243). They were fixed to 32 pixels before, but you can now make them smaller or larger. Configuration dialogs already support variable icon sizes, and I hope that more programs respect the customizable size in the future. Note that KDE currently offers only a limited set of available sizes (16, 22, 32, 48, 64, …) because with any other size they tend to get blurry (see image above). I was hoping that we could get freely scalable icons, but this requires support for SVG filters in Qt.

Frame widths

The platform’s style is also responsible for rendering all frames. I do not know of any style that has changeable frame widths, so with very high DPI displays, the frames currently tend to get too thin. This may be addressed in a future KDE release.

Spacing and margins

Regarding the spacing around and between widgets, I already wrote about it previously. The situation will get better over time, as more and more applications respect the style’s sizes and do not use fixed values. Oxygen itself currently uses fixed values, but I plan to add variable spacing to KDE.

You can help making KDE better by testing applications with the layout visualizer. Please report bugs for applications in KDE 4.3 that use hardcoded colors, spacings, font or icon sizes; add “[UI]” to the bug titles, so I can find them easily.

KDE Menu with medium-sized fonts and icons

KDE Menu with large fonts and icons

With KDE, text and icons can be scaled to different sizes (here using the Skulpture style)

Skulpture 0.2.3 released

Skulpture is a GUI widget style for KDE 4 featuring a classical three dimensional look with shadows and smooth gradients. Included is a matching window decoration for KDE 4. If you are looking for a matching Plasma theme, I highly recommend Atelier.

Despite the lack of time to work on Skulpture, I managed to get a small release out the door. This version only fixes a few small bugs in the widget style; the window decoration is unchanged.

Regarding the future of Skulpture, I have many plans, but not much time. The few hours I could spent went directly into KDE bug fixing, as I plan to make the switch to KDE 4. But you can keep me motivated by reporting bugs or suggestions ๐Ÿ™‚

Download link:

A note to packagers: If you have build scripts that fetch the source from a web address, please do not use the address, but use$VERSION.tar.bz2; I keep an archive of released versions (currently 0.1.3 and 0.2.x) there. This avoids breaks of build scripts on version updates.

KDE4 Skulpture Style

ARGB Window Themes in deKorator

The KWin team works hard to add support for ARGB window decorations to KDE 4. While it is not yet clear if the feature will make it into KDE 4.3 as planned, deKorator in trunk is now prepared to support these.

ARGB means RGB with alpha transparency. This color model makes it possible to have smooth rounding at the edges, while also allowing for different transparency levels in different parts of the decorations. For example, you could have the background of the window title be transparent, while the text and the buttons are opaque.

Only two lines needed to be added to deKorator to support ARGB. It had already been possible to use transparent PNG files, but the background was always filled with the Window color, instead of leaving it transparent. In a future version of deKorator the amount of transparency will be configurable to support the old method.

If you want to try ARGB decorations, you need:

  • a recent KWin from trunk/KDE/workspace/kwin (r957718 or newer)
  • a recent deKorator from trunk/playground/artwork/deKorator (r961812 or newer)
  • a deKorator theme that has (partially) transparent PNG files

Of course the choice of themes that have transparent PNG files is rare (1, 2), so you are invited to create your own theme, and make it available on

KCalc with transparent window decoration

Visualizing Layouts with Skulpture

Most complaints about the Oxygen widget style are about the large “whitespace” it has. To improve the situation, some deeper knowledge of Qt layouts is required. But before diving into the world of Qt layouts, let me start with a short list of Skulpture related news:

  • Skulpture on Ubuntu: Starting with Ubuntu 9.04, Skulpture will be part of the official Ubuntu repositories, so you can now file bug reports using the LaunchPad.
  • Skulpture on KDE 4.3: If you are using KDE from trunk, you should use the snapshot version, as this fixes some minor issues with ToolButtons and document mode TabBars.
  • Skulpture on Windows: User “SABROG” posted on forum CrossPlatform.RU that he has successfully compiled Skulpture 0.2.2 on Windows XP, as a pure Qt style (without KDE dependency) using the MinGW development environment.

Qt Layouts

The layouting classes in Qt are responsible for computing the position of widgets, taking into account their sizes. Empty space between widgets, the “spacing” property, is required to visually group widgets, as well as to make the user interface visually pleasing. A second property of layouts, the “margin” value, affects the empty space around widget groups and dialogs. Now there is an ongoing discussion about how much space is adequate, and how much is excessive.

In the end, the user should decide. On a device with limited screen estate, it might be reasonable to trade some elegancy in order to get more information displayed. One of my goals is to make KDE ready for customizable layouts. The application developer or designer must not set fixed spacing values in the user interface for this to work.

With Qt 4.3 the layouting capabilities of Qt improved significantly. A style can provide metric hints to the application using the layoutSpacing() and pixelMetric() functions; setting the layout spacing and margin values within the application is usually not neccessary. Unfortunately, old code or user interface description files might still set fixed values, either directly or indirectly.

Layout Visualization

The first (and most important) step is to make developers aware of this issue. Using Skulpture it is possible to change the layouting properties, but it is hard to see if the application really respects these style hints. With the latest Skulpture snapshot it is now possible to visualize fixed spacing values in layouts. To try this, add the following to the file .config/SkulptureStyle.ini:


Now if you run a Qt or KDE application with this style, the layouts will be colored. If you only see green lines around your widgets, everything is perfect; problematic layouts are indicated by differently colored backgrounds. I will write about the meaning of the colors and the possible solutions in a future announcement.

Visualizing a Perfect Layout (Qt Designer Settings):

Visualizing a Perfect Layout (Designer)

Visualizing a Problematic Layout (Session Management Settings):

Visualizing a Problematic Layout (kcmsmserver)

Minimalistic Window Decoration

There are already a few alternatives to the Oxygen window decoration available for KDE 4: Some ship with KWin, some are available on Common to all these decorations is that they have some rendering code, either using painting calls, or by combining PNG picture tiles in deKorator.

For Skulpture, I tried something different. As Qt supports MDI windows, the Skulpture window decoration client simply uses the Qt style to paint the window title bar decoration. This has the advantage that the code is shared between the two window types.

Using the Skulpture window decoration, you can make the borders as small as 0 pixels. You can also change the size of the title bar, because the glyphs for the buttons and the icon are scalable. See this image for an extreme example.

Now if you do not like the look of Skulpture, but prefer a different style, you might be interested in the experimental “QtStyle” option of the window decoration. This option can be used to select a different Qt style in Skulpture. To try it, edit the file .kde/share/config/kwinskulpturerc and add the following:


In theory, it should work with any Qt style. For example, this feature can also be used to get a Float style window decoration. If you like this feature, please tell me, so that I can improve it.

Skulpture window decoration using the Qt style Oxygen

Do not try this on KDE 4.0, though, as you hit the famous “green window title bar bug” ๐Ÿ™‚