Trolltech / Nokia Qt – Styles Could Be More … Stylish
One of the great things about Trolltech’s hard work into Qt has been the ability to use styles. It’s a great concept, not only that you can tailor your application to a native look and feel at the drop of a hat simply by switching the style used, but that you can even derive your own style from QStyle (or any style based on QStyle) to create your own look and feel.
It’s absolutely great!
…Except for when it doesn’t work.
I won’t even begin to go into a long rant on just exactly why the native-OS styles don’t have “emulation” to execute on non-native platforms (the very point of using Qt), even if it is at a performance loss. No, that Epic Fail is blatantly obvious and doesn’t need a whole blog entry just on its own.
No, what I’m going to talk about today is where styles are broken.
Take, for example, the great ability to use a brush instead of a color in a palette. In this way you can, most obviously, turn a background into not just a solitary color, but a pixmap, or even a gradient. You can do all sorts of funky things with brushes. It’s a wonderful concept in Qt. … Except for when it doesn’t work.
Now I don’t know just how many styles this affects, but I do know that while basing a custom style on QCleanlooksStyle I found a number of bugs, and while walking through some of them through the debugger they step back through QCleanlooksStyle into QWindowsStyle and even QCommonStyle. Now I get how some of these have been around for so long that maybe somehow someone just forgot that they needed upgrading.
Maybe.
Even if the ability to use a background pixmap has been around since Qt 3…
Or maybe there were just some serious bugs in Qt4.7.0. (When will Nokia get around to actually releasing the 4.7.3 SDK instead of a “release candidate”? And why didn’t they release a 4.7.1 or 4.7.2 SDK? For professional developers who don’t work off of anything “official” this is a grievous oversight.) But suffice it to say, turn on QCleanlooksStyle and then set your palette’s Window brush to, say, a gradient, and BAM! Bugs.
I think one of my favorite, one of the perfect examples, happens to reside right in QCleanlooksStyle itself. One of the nice things about Qt is that you can look at the code. And right there in drawControl, is little old QStyle::CE_Splitter. Now I love that the Linux world has taken things like splitters and sliders and made them more … visible. Lines and circles and dashes and all sorts of visual cues that this is something you want to touch. In other styles things like splitters can be darned hard to realize are movable objects.
But, one of the epic fails in the Cleanlooks implementation of the splitter is … the failure to properly support the brush of the palette. As soon as you un-colorify your palette, you’re asking for trouble. Because plenty of things in styles, like splitter, like frames for that matter, just assume that you want to fill in an area of space with a color. And be it a bug or by intent, at least in version 4.7.0, once you set a palette to use a brush it nukes the color. So if you ask for the color specifically, you just get black. And so all of those nicely colored areas are suddenly filled with black. Black splitters. To say it doesn’t look right is an understatement. And all because they try to fill a rect with a palette’s Window color.
Now, of course the easy solution would be to use the frigging brush! Obviously.
But the thing is, they’re trying to be fancy, to say, highlight a selected splitter by lightening up the color. Which works if your palette is only drawing with colors. But works not at all if your palette is brush-happy.
And yet, there’s an easy better fix. Instead of filling a rect with a 5% lighter color, why not use the awesome power of Qt to do something even better? Set the painter’s opacity to 5% and paint a white rect instead. Because that works just great with both color and brush.
Is it really too much to ask that the Trolls do a simple validation of their styles by setting a simple QLinearGradient Window brush to test the drawing of each and every style?
I can only hope that in future versions of Qt (heck, hopefully in the 7.4.3 SDK if it ever gets past beta into actual release) all of these style bugs can be fixed so that the beauty of Qt can truly shine.

Leave a comment