Image 01


Christian  Loosli
As I already mentioned in a comment before, this is a rather ugly and most of the time unneeded check. Just comment the mentioned line out for the moment, it will compile and work fine.

Fuchs - Jan 05 2010
Hi Craig,

This kind of check is a bad idea, as it causes at least gcc 4.3.4 (on gentoo amd64) to abort with an error because of the casting to int.

Otherwhise: great work, as usual. I am looking forward to tab support for the window deco, but in the meantime I just use oxygen for the borders and qtcurve for the content.

Kind regards,

Christian - Jan 05 2010

just wanted to know whether you are planning to support window tabs with KDE 4.4. Seems that the theme has to do it's part as well.

Would be nice to have this, as I really like the QtCurve Window Deco, but I also love to have tabs (coming from fluxbox)

Kind regards - Dec 02 2009

Fixed upstream, not confirmed yet as I can't be arsed to build a driver on Ubuntu from git sources. Sorry.

Thanks for the workaround, I guess you can change the default in future releases to use cairo again, but keep the GDK option for users facing this issue.

Kind regards,

Christian - Oct 12 2009
Hi Craig,

just as a sidenote:

I reported this intel upstream in the meantime, see

it seems that they are either aware of it or reproduced it, as they increased priority and severity of it.

In the meantime unfortunately karmic comes with intel 2.9 drivers, so as long as intel doesn't fix this / karmic doesn't include QtCurve 0.69, people will face this bug.

Thanks for the quick fix, let's hope that intel guys are as quick as you are. Workarounds could be removed afterwards (even though I am not sure whether cairo has any advantages, despite a slightly better speed)

Kind regards,

Christian - Oct 12 2009
Hi Craig,

Yes, it does, sorry for not replying to your mail earlier, unfortunately at the university the smtp ports are blocked. You should have received the mail in the meantime, now that I am home.

Kind regards,

Christian - Oct 08 2009

Craig looked into this, and it seems to only happen when the arrow is drawn with cairo. He can provide you a version with a fix.

However, it seems that this is an intel bug which should be reported.

Kind regards,

Christian - Oct 08 2009
Hi Craig,

yes, it is strange, and no, other stiles do not have this issue.

Please have a look at

as you can see (konsole in background) it only affects GTK+, and this only happens with new intel drivers. In 2.8 (which is currently default, but might be replaced in the future) this does not happen.

(In the screenshot you only see it for the scrollbar, however, drop downs like the firefox URL bar, drop down buttons, buttons like the back history in firefox etc. are also affected)

Kind regards,

Christian - Oct 07 2009
Hi Craig,

on my netbook I am using Ubuntu Karmic, and I noticed the following:

When I update the intel xorg driver to > 2.8 (via ppas), arrows (for submenus, for the back history of firefox, in drop down lists, in list views for collapsible items ...) are no longer drawn. This happens with V style arrows and with triangle arrows, but only in GTK, not in Qt.

Any idea why this might happen? How are these arrows painted in GTK+, and where is the difference to Qt?

I am using the official 0.68 QtCurve package.

Kind regards,

Christian - Oct 07 2009
Yes, Kopete 4.3 uses the new (qt4 based) contact list, so it is not affected. But I wont update unless 4.3 is released (not the RC)

Thanks for the version update.

Kind regards

Christian - Jul 06 2009
Hello Craig,

I just noticed that some Qt(4) elements are not affected by the new list style setting (qt4 and gtk different).

Best examples are the contact list of kopete (when the option to draw lines is enabled) and the folder list in digiKam.
There the lines look like in GTK.

Would it be possible to let this setting affect those as well?

Thanks in advance, kind regards

Christian - Jul 06 2009
Thanks a lot for the option regarding listview lines. I am quite happy with 0.65.2, no bugs, regressions or similar found so far.

Keep up the good work.

Fuchs - Jul 02 2009
Meh, okay, reasonable enough, but I will patch it back for my local installation to behave the old way in that case.

Thanks for the information.

Christian - Jun 29 2009
Woops, you are right, it was a triangle instead of a v, but it had a nice [] box around it and looked similar to the [+], probably that's why I was confused.

However, now this nice box is gone and it seems that the style of the lines drawn is different.

Here is a comparision: (with v instead of triangles, but this is not the problem)

behaviour I preferred:

new one:
(especially the gap for the last element looks ugly)

Probably I am just missing an option here, but I can't find which one.

Kind regards,


- Jun 29 2009

in 0.65.0 it seems I can't get the {+} symbol instead of the v-style arrows (tested in kmails mail view with threads), regardless of the setting I choose in the configuration.

Known bug, or am I doing something wrong? - Jun 28 2009
Well, it does not work for me :(

With qt3 apps (KDE_SESSION_VERSION=4) I get
and the application did not even react on colour changes after a restart.

In qt4 apps I get

The qt3 app is correct when I either use qtcurve 0.62.* (with qtcurve-qt4 0.64.*) or when KDE_SESSION_VERSION=3 is set.

Fuchs - Jun 15 2009
Another thing I discovered:

When using


Qt3 Apps (amarok 1.4, as an example) do not react to colour setting changes made via kde4 systemconfig. So I have absolutely no idea where it gets it's colour information from, as it is, despite the mouse hover, correct.

In the same environment qtcurve 0.62.7 works fine, even together with qtcurve-qt4 0.64.*

Regarding the things gentoo played with: They removed the KDEDIRS env variable, KDE_SESSION_VERSION was not touched.

Christian - Jun 15 2009
As an additional comment:

When I use KDE_SESSION_VERSION=3 /usr/kde/3.5/bin/amarok

the problem does not appear, with

KDE_SESSION_VERSION=4 /usr/kde/3.5/bin/amarok

it does ...

I will use the KDE_SESSION_VERSION=3 for Qt3 apps as a workaround for the meantime.

Christian - Jun 15 2009
According to env I have

fuchs@thinkfox ~ % env | grep KDE_SESSION_VER

when the problem occurs ...

But I am quite sure the gentoo people changed something regarding this recently, to allow a smooth parallel installation of KDE3 and KDE4. I will try to investigate futher, and of course try the new version as soon as it is out.

Thanks so far, kind regards

Christian - Jun 15 2009
Thank for the quick reaction on the above mentioned bug.

Another thing I noticed: it seems that the colour of the scrollbars / sliders/ buttons on mouse over (Plastik style) is wrong for Qt3 apps. It is brighter than for Qt4 or GTK apps.

Any idea, or probably wrong settings for Qt3?

Kind regards

Christian - Jun 14 2009
With Qtcurve-qt4 0.64.* I get a crash when closing several applications. Konqueror or the KDESVN logviewer are good examples.

Backtrace is:

Fatal Error: Accessed global static 'KCatalogStaticData *catalogStaticData()' after destruction. Defined at /var/tmp/portage/kde-base/kdelibs-4.2.4-r1/work/kdelibs-4.2.4/kdecore/localization/kcatalog.cpp:71

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f2892b5e760 (LWP 16393)]
0x00007f288dd5b165 in raise () from /lib/
(gdb) bt
#0 0x00007f288dd5b165 in raise () from /lib/
#1 0x00007f288dd5c4de in abort () from /lib/
#2 0x00007f289026119e in qt_message_output () from /usr/lib64/qt4/
#3 0x00007f28902612a2 in qFatal () from /usr/lib64/qt4/
#4 0x00007f28909beebd in ?? () from /usr/kde/4.2/lib64/
#5 0x00007f28909d7230 in ?? () from /usr/kde/4.2/lib64/
#6 0x00007f28909cbde0 in ?? () from /usr/kde/4.2/lib64/
#7 0x00007f28909d0151 in KLocale::removeCatalog () from /usr/kde/4.2/lib64/
#8 0x00007f289096110e in ?? () from /usr/kde/4.2/lib64/
#9 0x00007f28909606e8 in KComponentData::~KComponentData () from /usr/kde/4.2/lib64/
#10 0x00007f288dd5daa9 in exit () from /lib/
#11 0x00007f288dd484ab in __libc_start_main () from /lib/
#12 0x0000000000400909 in _start ()

This is only reproducable with QtCurve here, as soon as I switch to Oxygen, Plastique or other the applications don't crash.

KDE is 4.2.4, Qt is 4.5.1 on a Gentoo x86_64 system.

Kind regards
- Jun 14 2009
I can't reproduce this on Gentoo, with KDE 4.2.3, firefox 3.0.10 and gtk-engines-qtcurve 0.62.8

Could you export your qtcurve settings so I can try yours?

Kind regards

Fuchs - May 25 2009
For me (in 0.62.5) setting

style "qtcurve-menubar" = "qtcurve-default"
GtkMenuBar::shadow_type = GTK_SHADOW_ETCHED_IN
GtkToolbar::shadow_type = GTK_SHADOW_ETCHED_IN

xthickness = 2
ythickness = 1

in the gtkrc of QtCurve gets me the same menubar height in Qt3, Qt4 and GTK.

Might be because I don't use any borders in the menu, just highlights.

Comparison Nautilus -> Dolphin:

Fox - Mar 22 2009
I can confirm this for the KDE 4.2 UI. However, it seems to only break some settings, and by exporting / importing a theme this can be solved partially.

Would be great to see a fix soon.

Kind regards

Fox - Feb 20 2009
Wow, you are great.

I can live with hover not working, as long as the scrollbar is activated.

Can you provide me a diff file? Or is a release planned in the near future?

Kind regards

Fox - Feb 16 2009
Sorry, the bug is also reproducible with oxygen, therefore it is probably either a bug in Qt or in the fileview part of KDE.

Sorry for the noise, kind regards

Fox - Feb 15 2009
Oxygen (QT Style) seems to behave fine.

However, I only got this behavior with file view and it only happens in some folders (only containing folders seems best).

The other settings (raster size, width of text, font used ...) don't seem to affect much, at least I was able to reproduce the bug with all settings I tried.

Different question: is it possible to have the scrollbar grab mouse events on the far right even though when it is on the inside, with a border around the focussed scroll view?
Because having the scroll bar really in the right edge is part of human interface guidelines, as you don't have to aim with your mouse too much.

Thanks in advance for fixing this, kind regards

Fox - Feb 15 2009
Just to add something regarding QT 4.5rc: Building qtcurve-qt4 against it is no problem, and it shows up in the list. However, there is an issue with "Scrollbar on the outside" of Scrollviews: as soon as this is activated, applications like dolphin behave a bit strange.

There is a huge unused space between the folders and the outer right edge (where a scrollbar would be whenever there is a scrollbar) and you can get dolphin to switch back and forth between 4 or 5 lines of icons when resizing the window to a given size.

Would be great to see this fixed (hope you can reproduce it, try with folders only containing folders and the oxygen Icon set, plus dolphin from KDE 4.2), because scrollbar on the outside allows the scrollbar to be really at the edge of the window, therefore at the right edge of the screen when a window is maximized.

Kind regards

Fox - Feb 15 2009
Good to hear, thanks. In the meantime I found it in the sourcecode and removed the .darken / .dark method call, seems to work fine so far.

Thanks again and happy coding.

Fox - Feb 09 2009
Hello, thanks for creating this great theme. There is only one thing that disturbs me: KDE 4 uses a lot of those, I guess they are called dock windows. They are used as an example in the dolphin sidebar (information, places ...).

The small title bar of them is always darkened, which is quite ugly in my opinion. With other themes (oxygen as an example) those sidebar items are seamlessly integrated into the window.

Any way / chance to configure this, or do I have to edit the sourcode? (If so, a pointer would be quite nice).

Thanks in advance,


- Feb 09 2009
Windows Vista Aero Black

Beryl/Emerald Themes
by NikoBellic

5 .0
Dec 07 2009