“You look at your stylesheet in awe, amazed at your own artistic power. You have just styled your widget to perfection, and it is so beautiful one could cry. Now, just to finish off with that one-pixel adjustment to the left, and…. what!? Why does it suddenly look different?”
I am sure many of you have been there when stylesheets do unexpected things. This stems from the fact that the styles were not originally meant to support stylesheets and all the adjustment capabilities that come with them. So whenever a stylesheet tries to do something that the underlying style cannot offer, it falls back onto a different style.
For this reason, we are currently aiming at trying to make stylesheets a little more consistent and predictable, and there are several approaches that can be followed. I hereby invite the readers to post some comments about what they think is important with stylesheets.
You are free to write whatever you feel, but here are some guiding questions:
- What is your typical use of stylesheets? Giving widgets a brand new look, or just changing a color here and there?
- Is your program used on more than one platform?
No related posts.
12 comments
I don’t use style sheets for anything. I tried once, but found that changing the font size for a particular class of widget in a global style rule broke every single window layout in my program. Obviously, it wasn’t ready for use.
We use style sheets extensively; they have proven very useful for decoupling the look-and-feel of our app from the logic and structure. We set fonts, spacing, margins, backgrounds, borders and border images, and custom images for the widgets that support them. Our clients need an application style that differs wildly from any OS’s default style, so we’ve ended up with something that ought to look the same on all platforms. We are only targeting windows so I don’t have much information on how well it does that; I do know someone who runs our app on a mac doesn’t see any style sheet-defined backgrounds.
A few complaints and wishes:
– Performance is terrible! Turning off our stylesheets drastically reduces the time to both initialize and .show() widgets. This is my number 1 complaint. Setting wildcard rules (such as a default font for all widgets) slows rendering even more.
– We’ve ended up using the #id syntax and .setObjectName() as a hack method of defining generic classes that can be applied to many widgets. It would be nice to have a .class syntax and .setStyleClass() functionality on widgets.
– We set styles app-wide at load time; however we sometimes switch the style of a widget to represent a state change. It would be nice if either a) resetting the object name switched the style without another call to .setStyleSheet() or b) we had the .setStyleClass() fcn above and that did the same thing.
– There’s a bug where if you give a QMdiArea rounded corners, QMdiSubWindows show through the little corner masks.
– More styling options for tables would be great – for example setting a border-image on columns, rows, and arbitrary blocks of cells.
– Border images have a strange tendency to bleed into the center box of the nine slices, which I don’t think is the intended behavior.
– This is a tough one because of the constraints of the box model, but it would be great if relative positions could be set such that a widget actually overlaps another widget in a different layout.
Not using styles, here, since they aren’t supported on OSX. And I am not talking about QMacStyle which is known not to support stylesheets. The pagefold css in the stylesheet example looks different than on other platforms, even though another style than QMacStyle is used.
What is important for stylesheets? Make it available on all platforms, first
We work under linux and windows for commercial software application development. We have found widget stylesheets to be a very useful capability for allowing users to customize the look of certain widgets without them having to touch any source code. For commercial software, this is a real advantage. It is also very handy that the stylesheet syntax is very close to CSS, since it means end users can often re-use knowledge they already have if they’ve used CSS before. It is also very handy that we can provide a sane set of default stylesheets and then let users just override the bits they want.
An area we consider important is to improve consistency in what properties are available for what widgets. For example, as of Qt 4.3.3, QLabel still doesn’t support the text-align property, which is strange when showing text is its most-used purpose, yet QPushButton and QProgressBar do support text-align. Similarly, QLabel does not support the hover attribute, unlike all other widgets documented as supporting the box model.
We have also had some undesirable differences when using the “image” property where a QIcon-based non-SVG image automatically scales in an aspect ratio preserving way, whereas a SVG image does not preserve aspect ratio. SVG images expand in both width and height to take up all available space, but no option is provided to make it preserve the original aspect ratio and fit the largest image it can within the width and height constraints. This deficiency stops us from using SVG images in the image property of stylesheets in our particular application, particularly on those widgets which frequently change their size and aspect ratio.
On the positive side, widget stylesheets have proven to be very easy to learn to use from a developer’s perspective. We are very pleased to see their addition to Qt.
I use stylesheets extensively for both tweaking and completely changing the look of a widget. By far, the most common thing I do with stylesheets is set the border of QFrames. They make it so easy to do this, for example:
border: none;
border-bottom: 1px solid black;
I also use them a lot for QFrame background colors. I find it much easier than messing with QPalette, especially when it comes to alpha transparency, background images, and gradient backgrounds.
My number 1 request: Let us reference an external CSS file in our stylesheet. In my current project, I had to patch designer so I could apply the same stylesheet to all my UI files, and actually see that style in Designer while working with it. If I could refer to an external file, I would make each Designer form point to a single stylesheet file (foo.css or :/foo.css), such that I could use a global stylesheet for all forms in my project and actually see how it will look in Designer before building and running my program.
My number 2 request (much less important): Make it easier to change single elements of a stylesheet programmatically. I often have the case where, for example, I want to change a blue gradient background to a gray one (say, when my widget is disabled). My stylesheet also has dozens of other settings that I don’t want to change (like border color, fonts, etc). It would be nice if I could access elements of the stylesheets like a DOM tree, and modify them in place without having to do search and replace on a QString. Currently the way I do it is with CSS comments. I place a START and END comment and then do search and replace to modify styles programmatically. It’s a hack, and I would like more fine-grained control than that.
In short, stylesheets are absolutely fantastic. I love that you have taken a wildly successful web concept and merged it into the world’s best GUI toolkit. Thank you Trolls!
We’re using stylesheets pretty heavily on Win/OSX/Linux and while we’ve been able to get the look & feel we want, its been really tricky due to the resetting-ness of applying styles. We can’t set anything application-wide due to nasty side-effects of style.
We’ve been able to work around pretty much all the UI stuff, and are left with the performance issues that we’ve not (yet) found a way around. Our stylesheet is probably 50 lines, using selectors with and without wildcards. We push the styling pretty far, and I’m really happy with the final look, but if we can’t get better performance (startup time, in particular) then we may have to abandon the styhesheets and build a custom style instead.
Scrollbars have been particularly nasty to work with, due mostly to side-effects adding styles, but again, we’ve figured most of the tricks out. (but it took quite a bit of time).
Thanks, Jeff
We use stylesheets to force certain widgets to have a particular look and feel regardless of the OS that our program is running on and/or the QStyle that the user is allowed to choose from (e.g. QWindowsStyle, QWindowsXPStyle, QMotifStyle, QCleanlooksStyle, etc.). I really enjoy the flexibility that stylesheets give us to add some artistic flare to our program. We use a combination of internal (widget level) stylesheets and external (dialog/window level) stylesheets in our program.
I use the “Change styleSheet…” feature in Qt Designer extensively for widget level changes (e.g. QTableView { border-width: 1px; border-style: solid; border-color: #00129d } QGroupBox { color: #00129d }), which is *very* nice because you can see the change immediately if the syntax is correct (syntax check – another little bonus).
I load an external stylesheet if the stylesheet is long and involved. I have seen no performance issues related to using “internal” or “external” stylesheets. Keep up the good work and keep the stylesheet enhancements coming.
A style of an application is IMO not only the color, border and so on. For me it is the whole “what elements are visible and how they look like”-thing.
Customers say to us “this or that button shouldn’t visible for us”, so what we miss is a hidden/visible-property for widgets.
Currently I we have hacks like this in our apps:
QRegExp regExp(“QLabel#headlineLabel[^\\}]+\\{[^\\}]+visible: false;[^\\}]+\\}”);
QString localFilename = “.” + QUrl(qApp->styleSheet()).toLocalFile();
QFile styleSheetFile( localFilename );
if ( styleSheetFile.open(QIODevice::ReadOnly) ) {
QTextStream textStream(&styleSheetFile);
QString style = textStream.readAll();
if ( regExp.indexIn(style) != -1 ) {
label->setVisible(false);
}
}
As seems to me following example has unexpected behaviour:
QGroupBox { border-width: 1px; border-style: solid; }
Usually i try to use style sheets and than looking for different sollution.
Hi,
i’m looking forward to give our application a brand new look (it’s still only future plans, but i’m currently preparing our app for it).
Our app is running exclusively on Windows XP, using predefined hardware (including a touchscreen).
The most important thing for me would be a new sample application that allows a broader range of widgets to be tested, and that comes with more examples of stylesheets as well.
Maybe starting a website where users can post their stylesheets and vote on their favorite styles would also be nice
We use style sheets and custom styles when style sheets don’t give us all we want to go from a ugly application to a pretty one. It’s a nuisance sometimes to have to look at the qt code for private members to achieve what we want in the method of styling. I have to second the performance issue. Which we’ve mostly managed to get around by very rigorous original parenting to try and avoid re-parenting. I miss the earlier functionality of having bad stylesheet code break the entire style sheet, because it was a little more obvious when something was wrong.
I suppose the main issues we have are performance and area of control. So please make them faster and cover more things that can be styled.
I use style sheets to create complete custom looks. I did not experience any performance issues, but didn’t use wildcards much. I have to say that you are definitely on the right way with the style sheets. However, while the documentation got much better since 4.2, it still leaves a lot to wish for and the examples just don’t work sometimes. I had to figure out quite a bit of stuff myself, a lot of trial and error but in the end I had some success. I hope that 4.4 and 4.5 bring even better style sheet support and the documentation gets some attention. Anyway, keep up the good work!
Comments on this entry are closed.