Image 01


michael l
Dolphin Service Menus
KDE 3.5 Themes
Various KDE 1.-4. Improvements

KDE 3.5 Themes 404 comments

Score 58.0%
Feb 16 2007
This is a issue with the gtk-qt-engine. It seems it handles firefox's scrollbars differently. I can't do anything here. - Mar 14 2007
The problem here was, that both domino and knutclient used the global config reader. Domino changed the actual group to "KDE" to get its needed information, but knutclient doesn't use groups in his configfile and thus, with assumption it is set to the default "no group", it didn't reset it before reading.

The following patch resets the group after reading in domino: - Mar 14 2007
Will be fixed in the next version. But since I can't find out which mode gwenviev currently uses, smooth scrolling will only work with the scrollbars. - Feb 08 2007
from konsole/main.cpp:
COMPOSITE disabled by default because the QApplication constructor
needed to enable the ARGB32 visual has undesired side effects.

I guess this explains it. Konsole's noargb option will fix it for now, and also the issue with the transparent background ;)
Maybe it will be fixed (as a side effect) in the coming (bugfix) release, but this is just a guess.

Does the smooth scroll hack interfere with domino's or is it just replaced?
I have here opensuse in QEMU running and it looks like it is replaced (as it should be), but I can't say it for sure, since everything is a bit slow.
People have divided opinions on the smooth scrolling, some will accept the slowness, which comes from the smoother scrolling, and others not. Domino tries to take the middle way, which is imho not so bad. - Feb 08 2007
I think the kcommondecoration header was introduced in KDE 3.5. You are probably running an older version. If so, just update, KDE 3.5 is worth it. - Jan 31 2007
It will be fixed in the next version, which will be probably out next week. - Jan 31 2007
This is odd, since domino could access the pixels, the image should be there.
I will include your fix if someone else will provide the same crash output. - Jan 26 2007
This isn't directly related to domino and I'm not exactly sure what the problem is. Maybe it helps if you update your glibc and gcc. - Jan 18 2007
> What if you handle the shadow color of scrollbar
> handles differently (compared with button
> shadows)? For buttons, the shadow is around the
> whole element, for the scrollbar handle just on
> two sides (at the small ends). Therefore, there
> will always be a different kind of 3d effect. Eg.:
> Just the median of the outline and the scrollbar
> background color would help?

Another difficulty is that it's impossible to get the median of the gradient colors. For e.g. if the first part is white and the second black, which color should I take?

> That's a nice improvement. How can I configure
> Domino to look like the left candidate? Assume
> have to ait for the final release?

I personally dont like the left candidate. The textedit isn't round anymoe and the scrollbars look as they would have a 2 px line on the left or top.
But if you like them, add the following at line 6713 in domino.cpp:

case SH_ScrollView_FrameOnlyAroundContents: {
return true;

> > But if those lines trying to look
> > like a real button (shadows), they
> > are easyer to recognize. Just a rect
> > isn't natural and thus harder for
> > the brain.
> I disagree. Just draw a usual lineedit - my eyes
> recognizes it perfectly.

My fault, as I wrote I looked at a gkt style, where the lineedit and the button looked nearly the same (nearly plain rects...)
However if you have no problems with recognizing of the lineedits, you probably won't have them also with the comboboxes
As I wrote yesterday, it will all look better if you use midrange colors, thats also the color I use to create the pixmaps. To do the contours
right I should not only made the contour color customizable, but also the shadow transparency. But this would slow down the style even more.

> The button can still be connected to the
> inputline.
> One way is to insert the button INTO the
> lineedit,i.e. the shadow goes down to the input
> level and inside is the button. Alternatively, it
> could be tied to the edit box. Take for example
> the image you posted with the scrollbars and the
> textedit on the left side. Imagine, the textedit
> would be a lineedit, the scrollbar would be a
> button - there you are...

It's just a taste issue, but I like it how it is now :)

> I mean: The current tab should visually merge with
> the toolbars on top of it.
> The other tabs should just be (more or less)
> hidden, i.e. just the text and icons visible, but
> no tab-button drawn. To separate the tabs one
> should consider a small vertical line and drawing
> the tab on mouse hover. (see

This imo wouldn't fit to the rest of the style and there is no need that the konq tabs should look so much different (not really a perceptible improvement).

So, it's time to release somthing :) - Jan 18 2007
> o the scrollbars are lighter, that's nice. But the
> round line is still to heavy - should be of
> width=1px as all other lines.

The general countour width is bigger than 1 pixel (only a tad) and under the round line is a black shadow which makes it look bigger. If you set the contour color to black
you will see that the rounding is even too slim (or has to much transparency). That is the biggest problem if you create a style, it will never look right with all background colors. A static pixmapstyle would be sooo much easyer...

> o if a scrollbar is part of a box, two lines are
> drawn: the border of the scrollbar and the border

There's an option in Qt to draw them in another way, but the current way looks IMO better.
(yes I see this drawing bug ;)

> o inactive widgets: I gave black-murrine a try.
> works very nice. the problem: I can not
> distinguish between active widgets and deactivated
> ones (see for example Platik: There, a
> deacrtivated combobox is represented by a thin
> outline without any gradients - looks perfect and
> consistent).

Too late for this version, maybe they could be drawn half transparent, not sure now.

> o Color suggestions: Can I configure the
> background of the tabbar in Konqueror? Moreover,
> does it make sense to distuingish the gradient
> settings for: Top-tab, bottom-tab, konqui-tab?

IMHO not, the differences are minimal. For the background of the tabBar I added an hidden option "konqTabBarContrast". above 0 means darker, below lighter background color.

> o editable combo boxes!
> They just look, well, ... odd. It is the same in
> Baghira, Keramik, ThinKeramik, etc. - just too
> many lines!
> What is the problem? It tries to emulate a button.
> Thus the outer shadow shifts the combobox a level
> to the front. Then, it goes a level deeper again
> since the button is editable and, thus, a second
> shadow is required. Just too much for my eyes.

But if those lines trying to look like a real button (shadows), they are easyer to recognize. Just a rect isn't natural and thus harder for the brain.

> And: It looks odd, if one has inputlines and
> comboboxes in one dialog.
> So, is it possible to draw it as a usual inputline
> with some kind of connected button?

It's possible, but with a typical combobox you can clearly see that the button belongs to the lineedit. For e.g. Xara Xtreme has such a separated combobox. Just imagine every toolbutton would
have a frame like a normal button, it would be difficult to associate the right button with the lineedit - Jan 17 2007
Here it is:

Changes so far:
new config import option
fixed the scrollBar contour (maybe the shadow could be a tad stronger)
fixed progressbar gradient alignment
optional pressed shadow for sunken buttons - Jan 17 2007
Damn, you are faster as I ;)
I knew that I would have problems with that :( . I'm also not sure if I must link freetype. I will upload an updated snapshot within the next minutes. - Jan 17 2007
The margins are lying under the responsibility of the styler. In the meanwhile I got used to konsoles tabWidget margin, but you are right it was to big. It's now 2 pixels smaller. - Jan 17 2007
I don't know if such scripts are possible and if they are, I don't know how to do them. I'm not so good in this mathematical stuff. Btw. the mouse over effects for the gradients are planed for the next release, hopefully with a nice animation. - Jan 16 2007
As long as domino don't save the general color theme within it's config I don't like to ship any config files. But thanks for the config, I will use it on a screenshot.
About the popup edges problem: I tested all posible ways (which qt3 allows) and it seems it's not possible to fix this. I'm not sure where the problem lies, mayby it's beryls 1001 bug ;) - Jan 16 2007
An error like this: " '' has not been declared", means that you are missing the header with its declaration.
In most cases searching for the missing class (here KCommonDecoration) will show you which package will contain it.
So in this case its the kwin-developer package.

Maybe you will try a preview version of the comming 0.3 release: - Jan 14 2007
see my last posting. - Jan 14 2007
Sorry for the late reply.
The fixes are lying here you can just apply all patches.
But better would be if you would try the fresh preview release of the 0.3 version (need some testers :) ).
Some parts are not finished, like the pressed button shadow, and probably the scrollbar contour or lineedit shadow
If it doesn't compile or something looks odd, please inform me about it.
Thanks. - Jan 14 2007
> - Instead of * use a dot in password fields.


> - Lines of the focus-rectangle should be not
> dotted. Perhaps you could round the edges of it.

Thanks for reminding. I changed it to a solid line, but the rounded edges will apear only on widgets, which are drawn first into a pixmap
like the slider or color button. The problem here is, that some rects are drawn only with inverted screen colors and then the rounded pixmap edges wouldn't
be erased.

> - Fix that missing border-line on tab-widgets
There wasn't a missing border line. I guess you mean the top border line, it was just bright or
the white gradient replaced it, I can't remember now. The next version will have a new tab widget style
with dark and light border lines, but again with a low contrast (doesn't look good other way).

> - Using beryl as window-manager the shadows of
> popup-menues are not shown. Rounded edges are dark

I will have a look on this but probably after the next release. A broken plugin made Beryl here completly unusable, I can't even load the settings manager... - Jan 09 2007
> One wish, please add an config option for
> having "same-width" buttons.
> (I hacked it up myself, but for the non-coders
> here:)

I'm not sure what you mean with "same-width" buttons. The width depends usually on the content of the button + some space.
Maybe the toolButtons differ a bit, depends on the position in the group, but this is minimal.

> Is it possible to make the tool-buttons border
> just a bit thiner? (or maybe even
> configurable...?)

Yes, since yesterday the new thinner pixmaps are finished and the color of the contour will be configurable. - Jan 09 2007
The problems in the gtk-qt engine are already solved by its author in his svn directory. You can download it here:

I will release a (hopefully) crash free version this month, but if you can't wait you can patch the 0.2 version with this patches available here:
The one that fixes the vym crash is the missing_groupBox_parent_check.patch.

PS The next version will bring you nice half transparent disabled icons on non KDE applications (instead of the "holes") :) - Jan 06 2007
Redoing the pixmaps (to make them look good with bright colors) took longer than expected. I estimate I will be able to do a release at the end of this month, if nothing comes between. - Dec 09 2006
Here it is:

[Color Scheme]
windowForeground=0,0,0 - Dec 09 2006
From what I found, libXext is not the problem. Probably you miss some other dev packages, but which? It seems to be a common problem, but unfortunately nodody is ever posting the solution. I recommend you to install all KDE + Xorg-devel packages, with this you will also prevent further problems. - Nov 16 2006
> Thanks a lot for your style, i love it! Heres a
> suggestion: in the upper left corner, there could
> be like an arrow, as if it was a comic speech
> bubble, just for more eye-candyness ;). Thank you
> a lot

I'm pleased you like it. But I think the arrow would look misplaced if the popup pops up above the cursor and I can't forecast where it will do it.

> Somehow, i cannot see the menu in Amarok. I dont
> know why, as i can see other menues. Could you
> guess why??
Yes, sorry, the menu gets overpainted by the gradient.
Here is a fix for this:

This ones fixes some stupid crashes:

To use them cd into the domino-0.2 directory and
patch -p0 < (patches) - Oct 24 2006
I guess you are missing the xorg dev package. Could you post the error output here? - Oct 21 2006
This looks already better than the current one. I consider to draw the white part around the whole tabWidget like in the middle part of this screenshot. (I love this mac style)
By the way, most pixmaps are not finished and may change. The raised toolButton probably will get a tiny verical shadow when pressed, the sunken one its old one but lighter. The radio and checkbuttons haven't exact the same contour color as the buttons and the scrollbar is still the old one.
Today I try to do the scrollbar, with just a bit thinner contour and without the caps. - Oct 20 2006
Yes, this example looks good, but how should the gradient be drawn if there are only 11 buttons?
Another problem is that only KToolBar provides the getButton(int id) function. Without such a function, it is not possible to check if the button belongs to a group.
And in kritas case, it uses its own implementation of a toolBar.

If you like you can have a look at the current snapshot with a new raised button type.
It includes a try of a transparent rubber band (only iconview). One issue is, that it gets messed up when the cursor leaves the viewport rect and I'm too stupid to fix this. Maybe you are in the mood to have a look at it - or some other reader (eventfilter.cpp:221 and domino.cpp:3772)?

some options for .qt/dominorc
buttonContourType=0 | 1 (sunken or raised)
buttonPressedContourColor=#606060 - Oct 18 2006
Hi Lucher

> (1) The toolbox. Krita has a toolbar with 2 rows.
> It would be great if Domino could group the
> toolbuttons like it does for default toolbars.

Even if the grouping were possible (haven't tryed) I wouldn't know how to draw
the gradients.
In the case of three buttons: a vertical or horizontal gradient or a big one?
Imho there is no way to make it look good.

> (2) Widget sizes. Take, for example, the layer box
> on the right hand side of the screen: It has a
> combobox with layer effects and a spinbox for the
> degree. The develí¶opers tried to mimic Adobe's
> Photoshop gui by giving it very small font sizes.
> The tabs are drawn correctly, i.e. quite small.
> But not the combobox, the spin box, and certainly
> a few other widgets. The margin around the text
> seems to be fixed, but should be adjusted to the
> font size.

The Widgets doesn't have a fixed size, you see it on the color box.
The spinwidgets there have a small size and that buttons and comboboxes can also have quite small sizes, you see now and than in khtml.
I don't touch the minimum/maximum or fixed size settings, so it's all up to the applicaton developers and krita seems to be just inconsistend here.

And thanks for mention it :-). I changed the way to draw the text in the comboboxes, but forgot to take over the right font settings.

> The same sizing problem appears with the
> scrollbars. I know that Qt allows setting the
> scrollbar's width, but your style prohibits this.

The scrollbar uses a fixed size pixmap and adjusting the width would be problematic. While for enlarging I could split the pixmap and draw something in the middle (it would look like a round rect), for shrinking I see no way. - Oct 17 2006
Different gradients maybe, but not for the next release. I implemented different colors for the button contour and tint the pressed button gradients a bit darker now. If people will think it's still insufficient I will add it additionally.

The current color for the menuItem seems not to suit with some color shemes, have to fix this. - Oct 17 2006
I have changed some things with the groupbox (customizable color) and I can't reproduce the crash here.
Maybe this patch will help: - Oct 05 2006
I've played a bit with the shadows and found out that making it configurable is not so easy.
The shadowEngine, which is used for the icons on the desktop is too slow, but Xfs has the ability to draw the text with a transparency and drawing it nine times under the orginal text looks also good:

But this means I have to draw the text myself (direct access to xfs functions because qt3's alpha value is hardcoded) and I'm not a Xfs guru.
The problems I stuck on here are the right coordinates and localized text. If I don't find a solution we have to wait for KDE4 :(

Regarding the mouse hover effects: the button border effect which changes its color is finished, the surface effect is on the todo list.

Unfortunately the last two weeks I didn't worked much on the style (a bit frustrated), but I ordered yesterday a new monitor and probably at least pixmapping will make more fun with it :) - Oct 04 2006
Sorry, suse uses a patched k-menu with toolButtons on it, couldn't test it here on gentoo.
This patch should fix it (a kmymoney crash, also)
Use it from inside the sources:
patch -p0 < /path/to/domino_0.2_kicker_crash_fix.patch - Sep 20 2006
> yes, i mean both, but how can i load it?

The standard place for all style config files is /home/$user/.qt/

> Domino suits very well with dark colors, not to mention that's really beautiful.

Thanks, the next version will have a configurable button contour color and a new raised button type, which should make it suit also better with bright colors. - Sep 06 2006
Since you didn't wrote which one you mean, here are both: - Sep 06 2006
It's already on my todo list. It will be either configurable or tinted completely with the highlight color.
Currently the selected menuItem color is adjusted to the popups background color and is not configurable, the text color is taken from the highlighted text color sheme.
To fix this now, you can either darken the popups background, or change your highlighted text color, but this is probably not what you want :( - Sep 06 2006
Sorry for the late reply, currently I don't have a contract with an internet provider. Probably in two weeks I get access again :-(((

The problem is, that the alpha layers of the images are not blended together. For example, if the bottom one is transparent and the upper not, the result will be transparent.
In the meanwhile, with some help of Thomas Luebking and the code of inkscape, I got a working algorithmus and my problems are solved. Watch out for configurable button contour colors in the next release :-) - Aug 03 2006
Thanks for reporting, I will look at it. - Aug 03 2006
It seems you're missing the code compiler.
You need to install gcc first. - Jul 22 2006
Can you recompile it with this flag set: CXXFLAGS="-O0 -g3"
and post here the output of your backtrace? - Jul 21 2006
Thanks, actually I have a problem with the circe of the listViewExpander. Its a tad to bold and maybe too transparent.
I've tried to create a new one in gimp, krita, inkscape, xara, but they all hate me ;-)
Here is the old one:
The size should be the same and it should look good (antialiased) on dark and bright backgrounds.
Thanks and good luck ;-) - Jul 21 2006
> hi

> first

> second
The outlines of the widgets are intentionally a bit wider, this should be a
peculiarity of the style. With middark to dark colors they look fine, but
unfortunately I ignored the fact, that most users are using very light colors.
Maybe I will redo all pixmaps, but that will take some time.
The menu/popup items are indeed flat ;), I tried various effects on them and the
flat one looked best. The popupmenu has also a lightly bended flat look, so imho
it fits quite well.

> third
Yes, I will try to stretch it and put it in as an option.

> fourth
I personaly don't like it, but I can add some "flicker" effects if people like it.

> fifth
I don't like them also. Rounded corners are planed, but how exactly the entire
thing should look, I dont know.

> sixth
The ubuntulooks is the best gnome style I saw so far, although it still has a
tad of a "comic" look which I try to avoid.
Too bad I removed the rectangular scrollbar option (which was already in), I
will put it on the todo list again. - Jul 21 2006
You are useing a Xserver older than 6.8.99. The best you can do is to update
it. Or wait for the next release, which should come today or tomorrow. But
then you will have to live with a rectangular pressing area for the round
windeco buttons, if you notice a difference at all ;-) - Jul 20 2006
I broke them somehow. For now you need to restart konqi after style changes :-( - Jul 19 2006
> Wow, wow, wow!!! Though it crashes sometimes when
> changing options in kcontrol and when I have to
> restart KDE to apply the style to all apps.
With the crash you probably mean the groupbox configuration. I'm aware of it and
will investigate it.
The colors should apply correctly in the next release.

> Centered tabs

> focus indicator
Some people don't need it, so they can disable it.
Maybe I will addapt the shadow color to the font color instead the backgrounds.

> What about some horizontal gradient like in Brushed metal or some
> vertical gradient for the top widgets like in
> Tiger??
Not in qt3, it will be too slow.

> I am not a friend of these black edges on the
> scrollbar sliders, can you turn them off?
If you adjust the caps color, you will get "nearly" no caps, mostly you will see
that the gradient has a 1 px offset.

> If I change the color scheme I need to change
> all custom colors independently
Use the load/save option. - Jul 19 2006
Without a backtrace, I don't know how to fix this crash.
A configurable menu background will be in the next release :-) - Jul 19 2006
It doesn't happen here, so I don't know what it triggers :-( - Jul 19 2006
> You should however do something so that the gradients automatically match the
> colorscheme, and to simplify the configuration dialog. I got lost!
The colors are merely there for a short time, until the gradients will be
adapted. But maybe you're right and this is what is expected. I will change
this. The config dialog has indeed a usability issue, especially the tab page. I
tried to fix it with a highlighting of the selected tabwidget, but it helps only

> And please, make Domino clean up before it leaves ...
already fixed, will be in the next release - Jul 19 2006
Domino for openSUSE

KDE 3.5 Themes 7 comments

Score 50.0%
Jan 20 2007