The Road to KDE 4: Oxygen Artwork and Icons

One of the big visual changes just happened in KDE 4, the
transition of kdelibs to the Oxygen Icon set. This transition is
still in progress, and it includes a massive icon naming scheme
change that affects thousands of files. But, the Oxygen artwork
project much is more than just an icon set, it's a unified way to do
artwork for KDE 4. SVG an essential part of Oxygen, so many
applications that are now capable of SVG display are also using
Oxygen styled artwork. Read on for more...

Please keep in mind that the artwork I am showing today is a
work in progress, but shows things that have already made
their way into KDE's SVN as the new default. Oxygen will be the
default art scheme throughout KDE 4, but many of the elements can
still use some tweaking. If you have constructive feedback on any
of the artwork demonstrated today, the Oxygen team would be happy to
hear about it in the comments. :)

Back on the first of January, I wrote an article showing some SVG
widgets making their way into KDE, thanks in part to Qt's new SVG
capabilities. Some of the artwork shown in that article was
placeholders that were produced by the Oxygen team. Since then,
there have been improvements to much of those graphics, but the
really big visual change that just happened is the inclusion of the
new Oxygen Iconset into the KDE libraries as the new defaults.

Oxygen is a far reaching project, and extends well beyond icons.
They have a sort of unofficial tagline: "a breath of fresh air for
your desktop", which encompasses the look and feel of the whole KDE
environment. They are a team of developers and artists that are
dedicated to making things look beautiful. And not just shiny
effects either, they are ensuring that KDE has a unified, easy to
recognize interface. For example, icons that end up in toolbars all
have the same shadows below them to give them a consistent look.
Colour palettes have been created for the artwork to ensure that
icons don't clash with one another, and yet are still easily
recognizable. All of the icon sources are SVG files create using
Inkscape (and other SVG capable programs), and having the sources
available makes it easier to make simple tweaks to the SVG files.

We also now have an official icon naming scheme for KDE 4.
Previous versions of KDE grew the naming scheme organically as KDE
evolved, so it was somewhat random in many places. The Oxygen team
was responsible for developing parts of this naming scheme, but they
did so as part of so that there is less confusion
about icon schemes between Gnome and KDE (and other environments) in
the future.

So, rather than just talk about Oxygen, I have some screenshots
to show the icons in action.

Below is a screenshot of Dolphin showing Oxygen icons, and a shot
of Konqueror (from KDE 3.5.6) showing the same folder. Many of
these mimetypes also have previews available for them, when previews
are enabled.

You'll notice in the Dolphin shot that there are still a few old
icons sticking around, even though the Oxygen iconset includes
replacements to those icons. One of the biggest changes that
happens are part of the Oxygen transition is that many icons got
renamed. Old code may be referring to the old icon names, rather
than the newly corrected Oxygen names -- when the crystal SVG icons
are removed from kdelibs, it will become more apparent which names
are affected. For those who like the old icons better, they will
also get renamed, and be offered as an icon-theme within the KDE
artwork package.

As the Oxygen Icons have now been made the default, you will be
seeing them in all future articles in the Road to KDE 4 series, and
should get a better appreciation of how complete this artwork is.
Of course some icons still have room for tweaking, which is easy
thanks to using SVG sources. I'm not providing the screenshots of
the whole iconset in this article as you can find them in websvn or by
building KDE 4 yourself. The next snapshots of KDE 4 will of course include the new icons as they are now considered the default.

But, like I said, Oxygen isn't just about the icons. There are a
lot of other places within KDE where the Oxygen artwork is popping
up. Here is a shot of KDE 4's new logout dialog.

One of the biggest advantages to using Oxygen artwork in various
locations throughout KDE is that it is (mostly) resolution
independent. Which means, certain applications can be made to scale
to any size you want, and it will still look good. So, for
instance, if you are playing KBounce (from KDE Games), and you want
it to be big or small, it just adjusts the size for you.

So while KDE 4 is not a true, resolution independent desktop, and
this isn't necessarily a goal for KDE at this time, some KDE
components do now operate on a resolution independent basis.

There is another two elements of Oxygen currently in development,
that are not yet complete. These are the Oxygen Widget Style, and
the Oxygen KWin Decoration. These have not yet been made the
defaults for KDE 4 as they are not yet far enough along. But owing
to the fact that it has not yet become the default for KDE, I'll
decline to show it off just yet. Just bear in mind that the Oxygen
Icons and related artwork are just a few elements of the Oxygen
project. The Oxygen team is making a lot of progress on the Style
and Windeco, but this whole project is an enormous amount of

There are also other visual elements of KDE 4 underway that do
not directly involve the Oxygen team, but will work together with
them when required. These are things like KWin's composite branch,
or the Plasma Workspace theming capabilities.

For those that are interested in helping KDE out through
artwork, you should visit #kde-artists on and get in
contact with some of the artists there. They are quite friendly,
and take constructive feedback from artists and non-artists

Individual KDE projects are also looking for artists: Recently,
Carsten Niehaus of Kalzium put out a request
for some help producing some kid-friendly icons to represent the
elements of the periodic table in an optional kid-friendly layout.
Anyone up to the task should visit the #kalzium irc channel.

Also, the Amarok project has recently informed me that they are
in need of some artwork for their upcoming 1.4.6 release (for KDE
3.5.x) which doesn't need to be Oxygen styled, as Oxygen is intended
for KDE 4. Join the #amarok irc channel if you're interested, and
talk to 'markey'.

Editorial aside: I'm glad that so many people are showing
interest in KDE 4's development, but please try to provide
constructive feedback to help improve KDE 4. Many of the developers
read the comments on the dot and implement things that users request
if they are well-reasoned. For example, Peter Penz implemented the
Tree View in Dolphin, and Rafael Fernández López made changes to the
Job Progress Manager based on your constructive feedback. Your
feedback is very welcome, but as last week's article has shown, when
the comments get out of hand, it becomes harder to sift through them
for the constructive ones. On the flip side, that article
absolutely demolished the previous comment records.
Hopefully we can break those records again one day as the interest
in KDE 4 grows. Until next week...


by reihal (not verified)

This is about noise and information. The empty space here is annoying,
it acts as noise to my information gathering. It could instead be filled
with information, adding to the information content.

by Arnomane (not verified)

If you want to save even screenspace of menu bars in all of your (KDE-) apps, enable the Mac-like menu bar on top in KControl.

by reihal (not verified)

Best thing would be to have all bars autohide like Kicker.

by nick (not verified)

toolbars are useles for people who know about 'Configure shortcuts' dialog.

by Torsten Rahn (not verified)

You didn't read the article, did you? That empty space is what you need in some places to make stuff look good and _not_cluttered_ . I'm not opposing to make it configurable in some ways. But please acknowledge common usability findings and decades if not hundreds of years of experience that designers have gathered.
What you are aiming for is obviously a setup for somebody who wants to squeeze the last bit of efficiency out of each pixel. That's a good thing for you as a person, but keep in mind that it might not be the best for everyone.

by reihal (not verified)

Still no.
The toolbar is a tool, not art. The headline of the article is: "White space (visual arts)"
Form over function sucks, function over form rules.

(My fault is to write this here since it seems to be the concern of Qt, not of Oxygen.
You could do it in KDE 1)

by Torsten Rahn (not verified)

> Still no. The toolbar is a tool, not art.

A tool - especially if it's in wide use - is always subject to considerations of look and feel. Due to the sheer importance of look and feel in today's world you've got to make compromises between better looks, better usability and flexibility.
What you obviously think about when talking about usability is efficient and comfortable usage of a kind of poweruser who doesn't care about esthetics. However that's only one small part of the whole broad spectrum of users KDE supports.

> My fault is to write this here since it seems to be the concern
> of Qt, not of Oxygen. You could do it in KDE 1)

I remember someone from Trolltech having said that it was dropped because nobody really used it. And worse: I have seen many people who "lost" their menubar in Windows and KDE 1 because they managed to move it in some way out of sight.

by neurol23 (not verified)

if menubar could have been "lost" in windows, then it was a windows bug.

it's sufficient to implement the functionality. no need to replicate the bug also ;-)

by reihal (not verified)

"a kind of poweruser who doesn't care about esthetics"

I'm not a poweruser (whatever that is) and I do care about esthetics.
If you had looked at my screenshot you would have seen ample amounts of
white space, but in the content where it belongs.

I just don't think an empty space in the upper right-hand corner of every
application is good esthetics or good usability.

"someone from Trolltech having said"

I am sure Matthias Ettrich can hack this during a coffee break or some such.

by soc (not verified)

I think that's one of the most important reason i neither use epiphany nor konqueror, but firefox.

In my opinion we don't need 90% of the options to configure the toolbar, we need just ONE function to make the menubar behave like many people want and expect it.

There's a screenshot of my firefox in the attachments.
I would never suggest configuring konqueror like this as a default, but the people who want to configure it, should be able to do it.

by nobody (not verified)

You can remove the menubar in konqueror (it's set to the keyboard shortcut ctrl+M by default) and disable/enable whatever toolbars you like, so you actually can make konqueror look like that pretty easily. Saving the session so that it starts up with the menubar disabled is kind of tough (since the session save option is on the menu), but if you temporarily put the option in a toolbar or as a keyboard shortcut you can do it.

by reihal (not verified)

I don't want to remove the bars completely, I want combine them to one bar.
That includes the grab-bar too, only one bar at the top is enough.

by kollum (not verified)

You probably mean something like that ! (see atached screen shot, which is in full screen mode)

You have to right click a tool bar an choose "configure tool bars" in the bottom.
then, add and remove what you whant to be on you "one line" pannel.

Finaly, go to "configure", then toolbars, and unselect everything but the one you customised.

use ctrl + m to hide the menu.


by soc (not verified)

I already tried the hint with the menu, but I just don't like it.
- I want to be able to access the menu without activating it and deactivating it after use. There a so many icons for doing useless things, but this one is missing.
- It looks like crap, even the adressbar isn't vertically centered. There is way to much vertical spacing, but no horizontal spacing at all. This is due to the fact, that you can't make the icons smaller than 22*22 in the gui of konqueror, which wastes screenspace and looks horrible.

by soc (not verified)

I have to correct myself:
- I just saw that if kcontrol is installed you can set the icon size from there for all programs, including konqueror.
- I installed the QtCurve theme, now many things look quite good, compared to the default ones provided with kde 3.5.

Sorry for my mistakes!

by Matt (not verified)

It looks like it's coming along really well, I like this look much more than crystal. The only suggestion I have is regarding the general kde color scheme. I realize that blue's a popular color but it'd be nice if there was a green or brown version of these for those of us who don't like blue.

by Jonathan (not verified)

Brown would be great. I'm currently using a brown theme. The problem is the coloring of the icons. I mean, these colors are defined inside the svgs, right? So this could get quite difficult

by Aaron Seigo (not verified)

colour is indeed great. think of a painting full of beautiful, rich colour. now consider a frame that is just as colourful. imagine using that same frame on every single painting, regardless of the colours in the painting. it would look pretty bad.

that's what our action icons are: they are art that frames the real show: the application. they should be atractive, recognizable and get out of the way without conflicting with the contents of the application's informational display.

you may note that mimetype, filesystem and device icons are more colourful and application icons even more colourful yet. action icons are, due to how and where they are used, purposefully muted and kept simple when it comes to colour and shapes, however.

by Diederik van de... (not verified)


I just got a MacBook, and noticed how all toolbar icons are in grayscales. So far I noticed:
it's beautiful.
doesn't sit in my way.
feels really uncluttered.
doesn't demand attention when I don't need the toolbar.
let me focus to what's really important.
macs also have really colorful icons, exactly for applications.

So I feel Oxygen is going to become a key element to make KDE feel uncluttered. :)

by Debian User (not verified)

Have you used Icon Effects?

These allow you a lot of things, including general manipulation of colours. I personally reduce the saturation, which turns the blue into a light grey/blue, which I find pretty, but you could mess around more. There is even a nice GUI for it.


by Justin van Wijn... (not verified)


Thank you for these wonderfull updates! It really makes my day. The progress in the new icon set is really nice.. I like them all! Well except the tar one, maybe that one is still beeing modified?

Is there also some progress at the "sound theme" ? It would be nice to hear something about that.

by Troy Unrau (not verified)

The sound themes are still very much a work in progress. I know there is progress, but I haven't really looked into it so far. They don't present themselves as well as screenshots do either, sadly. :P

by Sebastian Werner (not verified)

Does this mean that Oxygen is naming compatible to the freedesktop standard? Does this mean that it really use the same names as tango for example? That would be really great!

With the KDE4 release, do you think it is possible to dual license the artwork under LGPL/EPL. That would make it possible for us, the qooxdoo developers, to also use the Oxygen icons in our JavaScript Framework qooxdoo ( which is also under LGPL/EPL.

by shamaz (not verified)

As far as I know, oxygen icons are compatible with the freedesktop standard, and "licensed under a creative commons v3 attribution, share-like license" (

by Jakob Petsovits (not verified)

1. Yes, it does use the icon naming specification (the one initially published by the Tango team). So you can load Oxygen as a GNOME theme and get happy with it.

2. Stemming from KDE's requirements, it currently has a few more standard icons than what is specified in the icon naming spec. Which means that KDE applications will make use of those "non-standard" standard icons, and KDE applications won't get all the required icons from a theme that restricts itself to "standard" specified icons.

That's mainly because the icon naming specification has strong roots in GNOME/GTK+ naming, and the Oxygen team has to work together with the Tango team to get more of the important KDE stuff into the naming specification. It's a matter of communication, but now that Oxygen actually follows the overall naming specification scheme, it will be a lot easier to work out.

I'm looking forward to kdelibs just containing icons from the spec (and a few additional application icons), and the spec containing all icons that are for KDE apps. Let's see how this works out.

by Aaron Seigo (not verified)

yes, we're hoping to move at least some of our icon names up into the spec where there are gaps in the spec. this will likely happen post-4.0 as things shake out and firm up more.

by Debian User (not verified)

Having read I doubt that this will happen. Not only can you use the Icons without attribution then, but also claim them for yourselves, under restrictive license.

Look here from techbase:

Image previews of Oxygen are released under the Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License. This is to keep Oxygen fresh for KDE 4, that will be released sometime in the middle of 2006.
The Oxygen icon theme will be released under a GNU License. Most likely, this will be LGPL - however there is hope to have an official GNU License for icons/images by that time.

So before KDE release the Oxygen Icons are not even Free. Afterwards they likely still want to be them KDE icons, not Eclipse icons.

Yours, Kay

by Aaron Seigo (not verified)

the license changed last week before being brought into kdelibs. the CC v3.0 share alike, attribution license is now being used. it's an art appropriate license that affords the freedoms we expect from similar licneses we use with our software.

by Petteri (not verified)

Ok, Cool. So hopefully this means that the new licence (cc v3) is compatible with debians DFSG?

by Aaron Seigo (not verified)

i don't think this is a settled question yet, sadly.

by Mootjes (not verified)

Great to see Oxygen evolving as much more than just an icon set. The team really gives a professional look to the desktop, and that's what gets me most excited. Congratulations to the excellent team!

by Darkelve (not verified)

I just browsed through the icons and they are lovely.

1. Something about the 'audio folder' icon does seem a little odd to me. The icon here:*checkout*/trunk/KDE/kdelibs/pics/oxygen/128x128/p...

Compared to most of the other icons, this icon almost seems bland; I mean the speaker part, not the folder part. I don't particularly like the yellow border of it either.

Well, maybe that is just a personal feeling.

by Ben (not verified)

> Well, maybe that is just a personal feeling.

It is, I like that speaker. Then again this is art, its _all_ going to be personal feelings :)

by Ben (not verified)

In KDE3 you can chose an icontheme in the control panell. in KDE4 will we be able to take the MIMEtypes from one iconset and the apps from another. And an individual icon from a third. (without manageing jpgs in ~/.kde/)

For example, I may chose the location icons from cystal, the rest of the icons from Oxygen, and download a debian spiral for opening the Menu.

by Vasiliy Faronov (not verified)

I like the icon set in general, but the shadows annoy me. Look at the “Back” & “Forward” icons from this article’s screenshot. Then compare them to, say, Tango. In Oxygen, the shadows are way oversaturated and appear like an important part of the icon (which they are not). Whereas in Tango, it’s just a vague gray spot beneath the icon — you won’t really notice it unless you specifically pay attention. And from what I can see, this is a problem with many other Oxygen toolbar icons. I hope something can be done about this before the release.

by shamaz (not verified)

I agree. Actually I don't understand why the shadows are included in oxygen icons... Everybody is talking about the benefits of SVG (scalable, modifiable etc.) but we don't use them !! I'm sure it's feasible to add the shadows _at runtime_.
This would have several benefits : less encumbered svg icons, less duplication in svg sources (-> easier to maintain), *customizable shadows* , action icons more reusable for other things than just icons (ex: animation, games) etc. etc.

The only problem is... it can impact performances. But I think it could be OK if we have a "disable icon shadows" somewhere :)

I really hope the oxygen team will consider these possibilities !
The ideas of Aaron ( would surely help in this case.

by logixoul (not verified)

Agree 100%

by furanku (not verified)

I also agree.

Shadows could be a useful extension if they would provide some information. As one can estimate if an icon is "on" an window or "above" by its shadow, this would give a "2.5 dimensional" impression of a flat 2D Desktop. That is an easy to understand, intuitive and unobtrusive way to show the "state" of an icon. It would be a pity not to use it by "hardwiring" the shadows into the icons just as eye candy.

Especially since active window and menu shadows are used that way: To guide the users eye to the active and therefore topmost element on the desktop.

by ac (not verified)

..or you could set the shadow stuff when you select the theme. Then it generates the theme using your custom shadows and you have no overhead as it would then use your generated custom svg files basically derived from the original/default. Perhaps that could even be applied to more things about the icons.

by Leo S (not verified)

*customizable shadows*

Oh dear god no. If KDE4 has an option like "Icon shadow colour" or "Icon shadow size/angle" then the usability team might as well go and hang themselves :)

by zenity (not verified)

Shadows soft|strong|off would be enough for me.

I really REALLY don't want shadows under my icons.

by Torsten Rahn (not verified)

That "brilliant" idea has been floating around since years already. Believe me: it's neither as easy to accomplish nor is it always desirable. A hand tuned shadow at small sizes will always look better than a plain algorithm.
The objects depicted on icons will look strangely stiff and non-vivid if you apply a uniform automatically applied shadow to them. We already did such experiments with the HiColor icontheme in KDE 2.x and in the end decided against that feature.
I'm sure you're either a programmer or at least you never drew a larger set of icons.

by shamaz (not verified)

Actually, I do NOT understand why it can be a problem.
Talking about kde 2.x seems off topic to me here.
I'm talking about SVG icons here, not fixed size icons.
Most (all ?) of oxygen icons use the same template for shadows. So the XML code of this template is inside each icon XML source.
There are several way to compose the shadow and the icon :
a) render them separately as bitmap and blend them.
b) merge the XML sources of the icon and the shadow together (via XSLT, DOM or whatever you want), and THEN render it.
c) I'm quite sure there are other ways ;)

I understand solution a) can make strange looking icons. But I don't see why the b) solution could be bad. If the transformation is applied correctly, the resulting source should be the same isn't it ?
Please elaborate a bit :)

ps: I'm a programmer, but you are right : I never drew a large set of icons :).

by cossidhon (not verified)

First of all, great article.

In all the Gnome vs KDE flamewars it seems to boil down to the same conclusions: KDE is (much) better in functionality and is better engineered, but Gnome has the slick and clean user interface. I agree with these people. I too find the current default Gnome interface (metacity with clearlooks) very well designed and a pleasure to work with. It is my hope de Oxygen style and decoration will mimick this as much as possible. Also, the way the items on the taskbar in Gnome look is great. They are outlined and this is currently not possible in KDE3. Don't even know if this is themeable or not. Maybe a good idea for KDE4 then?

On a different note, I noticed Dolphin got the nav-bar. That's great, but I would like to see the nav-bar further integrated into KDE, such as in the file selector, etc. Again, just like in Gnome.

Look at for what I mean.

If these things would be implemented in KDE4, I am sure it will win over a lot of Gnome users (and hopefully even Novell) to KDE.

Just my $ 0.02

by Anon (not verified)

"First of all, great article."

Agreed :)

"In all the Gnome vs KDE flamewars it seems to boil down to the same conclusions: KDE is (much) better in functionality and is better engineered, but Gnome has the slick and clean user interface. I agree with these people. I too find the current default Gnome interface (metacity with clearlooks) very well designed and a pleasure to work with."

Agreed :)

"It is my hope de Oxygen style and decoration will mimick this as much as possible. Also, the way the items on the taskbar in Gnome look is great."

I've been playing around with the Oxygen style and Windec for a while now, and I fear you may be a little disappointed - it looks great and refreshingly un-Windows-like (though I would fully expect the hard-core KDE detractors to continue shouting "lok KDE == teh windoze!1" even if it looked 100% different in every way), but if I were to compare it to existing desktops, I'd say it looks to me more like OS X than GNOME.

"They are outlined and this is currently not possible in KDE3. Don't even know if this is themeable or not. Maybe a good idea for KDE4 then?"

The Kicker (which houses the taskbar) will be killed off in KDE4 in favour of Plasma. I think a while back that aseigo said that there will be a Plasma DataEngine for the taskbar, so you will probably be able to grab a taskbar implementation that suits you from Hot New Stuff.

"On a different note, I noticed Dolphin got the nav-bar. That's great, but I would like to see the nav-bar further integrated into KDE, such as in the file selector, etc. Again, just like in Gnome.

Look at for what I mean."

This has certainly been discussed and is wanted by several devs (a strong emphasis on shared code/ components is a KDE hallmark, after all). I guess we'll have to wait and see if such a move would cause any usability issues.

"If these things would be implemented in KDE4, I am sure it will win over a lot of Gnome users (and hopefully even Novell) to KDE."

From my experiences on the heavily GNOME-centric Ubuntu Forums, it seems that a surprisingly high number of GNOME users are keeping a close eye on KDE4 with a view to switching if it proves to be to their taste. Many of the real die-hards, of course, will continue to make excuses - I know of several people whose *sole* reason (they admit this explicitly) to not use KDE is that most of the apps begin with "K", which is frankly the most ludicrous reason I have ever heard. So expect some new convertees, but not a mass exodus :)

I think you'll find that Novell's choice of GNOME - which, according to most surveys I've seen, is the least favoured desktop by a factor of 2:1 - is grounded more in politics than anything else, and an aesthetic face-lift in KDE4 will not cause them to switch.

Just my $ 0.02

by Anonymous (not verified)

> I'd say it looks to me more like OS X than GNOME.

And this is bad how? ;-)

by djouallah.mimou... (not verified)

" I think you'll find that Novell's choice of GNOME - which, according to most surveys I've seen, is the least favoured desktop by a factor of 2:1 - is grounded more in politics than anything else, and an aesthetic face-lift in KDE4 will not cause them to switch"

of course it is hard to accept that and we all know that redhat novell ubuntu have choosen gnome over kde just for the license.

honestly ISV don't pay Microsoft or apple to develop software for their platform. and how they are supposed to do that for linux.

imho as long as qt is under gpl gnome has always an advantage over us.

i know it is not politically correct to say that but this the truth.

by demise (not verified)

"Look at for what I mean."

You mean ?

The default sized dialog there is only able to show 3 1/2 directory entries. Now that is awful, terrible! What kind of use cases do GNOME developers have? I normally have at least 10-40 entries in every directory. The KDE file dialog normally shows ~13 * 4..6 = 52..78 entries there.

Forcing me to scroll every single time certainly decreases productivity and usability a lot. KDE 3.5.x even has that navigator. What are we missing now? Huge Add and Remove buttons for the navigator?

by Sutoka (not verified)

I'm not a fan of the GTK file dialog (in fact, i loathe it), but the default dialog size shows more than 3 1/2 icons, I think either that dialog was scaled down (the KDE one defaults to really small as well, you won't be getting 52-78 without resizing it), or the extra archiver options at the bottom cut away most of the dialog without increasing the default size (which is actually what I think happened). On my system the GTK file dialog will show 9 icons (and its about twice the size of the default KDE file dialog I believe, which probably shows as many if not slightly more).