Say No to Qt Style Sheets

https://doc.qt.io/qt-6/qstyle.html has some example code, as well as https://doc.qt.io/qt-6/qtwidgets-widgets-styles-example.html. The look is definitely not modern, but the API hasn't changed, and everything you can do with a stylesheet, you can do with a style subclass (and more).

Indeed stylesheets can call into the palette. The default behavior though, when the stylesheet doesn't mention colors, doesn't play well with the palette. See the documentation for QWidget::setPalette which says "Warning: Do not use this function in conjunction with Qt Style Sheets.". And I remember hitting such problems, they are not just theoretical. I don't have a testcase at hand though.

We have a widgets app styled completely with style sheets and we're happy with it. I did not find the QStyle method to be very accessible.

We've integrated the SASS stylesheet compiler into our app so that we can determine some parts of the style dynamically, based on platform, DPI, and potentially user preferences like high contrast etc. This gives us access to much better syntax and better selectors too.

I'm glad to see diverging opinions, debating makes things interesting :-)

The need to write an additional library on top of what is provided by Qt, partially proves the point that the stylesheet support in Qt is not completely optimal, though.

About the points being theoretical: they all come from our own actual experience. For instance the one about wanting not to affect the style of file dialogs on Linux is the reason I ported the opensource music application rosegarden from Qt stylesheets to a QStyle.

I work for a large game developer which uses Qt extensively in its tooling. We use QSS across our tools and have found that QSS does in fact extract a pretty substantial performance cost in instantiating widgets, but also reparenting widgets (as the style is reset).

What this means is that ordinary small dialogs and general UI will not pay a measurable price, really depending on the number of widgets you have in any given panel. However if you are displaying any UI with many widgets or have panels which regularly need to rebuild complex layouts (such as a property editor panel) you will pay a very high cost. On modern machines the "polish" style update phase for widgets will be several milliseconds each, which adds up pretty quickly for situations where there are many widgets.

So the general rule of thumb is: few widgets with static layouts and few refreshes - you'll probably be fine - many widgets in complex nested layouts, with frequent tear-downs and refreshes - you will run into some substantial trouble.

Today I hit more limitations in Qt stylesheets, proving the point that they don't allow implementing 100% of a style requirement that doesn't keep within those limitations. Qt stylesheets allow to set the text-align property to right-align the text for a QProgressBar, but there's no way to add some padding to the right of that text so it doesn't collide with a rounded rect for instance (because the text isn't a subcontrol, and there's no property like text-padding). Similarly, a stackoverflow post(https://stackoverflow.com/questions/68441094/qt-stylesheet-controlling-progressbar-text-highlight-color/73387635#73387635)) points out the inability to change the color of that text when the progressbar runs into it. And finally, there's an issue with rounded rectangles of very small sizes (e.g. for a 1% progress value), the stylesheet code gives up making it rounded and just makes it square, while QPainter::drawRoundedRect() actually works when doing this in a QStyle. I'll soon record a youtube video for the KDABTV channel, to show this more graphically.

The ability for users to customize things is undoubtedly the appeal of stylesheets, and QStyle doesn't offer that out of the box (the only way to get anywhere near that is to read configuration from the C++ style code, which allows for some things but is of course not as flexible).

"Qt style sheets are currently not supported for custom QStyle subclasses" doesn't really make sense to me, actually. I don't see how this is worse than the usual use of stylesheets, applied on top of the default widget style. I suppose someone hit some of the problems mixing styles and stylesheets (as in our table row that talks about mixing) and added this as documentation (I can't get more details though, this bit of documentation predates the public git repository for Qt).

So yeah, I think it makes sense to provide a QStyle and still let users play with stylesheets on top for light customization, as a best-of-both-worlds compromise.

All this applies to Qt 4, 5, and 6, there hasn't been a major architectural change in that area.

One issue I've experienced with QStyle & Qt stylesheet compatibility is to do with that the underlying QStyleSheetStyle class doesn't provide public APIs for many of the basic details specified in .qss. E.g. you can't easily get access to the box model parameters applied to any given widget, so any QStyle code other than QStyleSheetStyle can't easily conform to the design specified in the stylesheet in many cases. This is compounded by what seems to be a reluctance of Qt themselves to do anything about it..... For example there's a long standing bug that Qt seem to refuse to fix as it seems to just get closed everytime it's reported, namely where if the stylesheet tries to apply "dynamic" styling to tab bars/tab widgets (e.g. using "selected" psuedo state etc.) the underlying cache implementation for stylesheet evaluation doesn't update the space calculation for the tab text so you can easily get the text colliding with the tab outline, and since the details are private, there's no way to fix it, other than maintaining your own patch to Qt. Sorry I don't have details to hand to list the QT-BUGs invloved..... and it'stricky to find as it goes back to trolltech days.......

Hello,

Thanks for your comment. There's no doubt that stylesheets are easier in many ways, including writing and reading. Which is why, if they do the job for the task at hand, they're fine. But I wanted to raise awareness that their possibilities are limited, and therefore writing stylesheets for complex styling needs, is a risky investment: if you can't negotiate with the style designer to remove requirements that can't be implemented with stylesheets, you'll end up having to scratch it all and rewrite it as a widget style.... See the example I mentioned in an earlier comment about the progressbar text colliding with the right edge of the groove; no way to move it a bit to the left. Then what.... That stylesheet was indeed easy to write, but the issue is not fixable...

In terms of SVG, that's certainly feasible. The common solution is to use QSvgRenderer in the widget style, to load the required SVG files from disk (or qrc resource) and paint them each into a QPixmap that's kept around. QPixmaps are then fast to blit on screen; rendering SVG - or worse, parsing SVG - at every paint operation is quite costly so we don't want that.

Completely understandable, but then don't title the article "Say No to Qt Style Sheets". A better title would've been "The Pitfalls of Qt Style Sheets" or something. It would be less decisive and adversarial.