StyleKit
-
Hi,
Nice ! It's looking awesome !
One thing that you didn't mention is how it compares to the stylesheet QStyle. Does it also "break" the control style as it is not using the platform style ?Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
This sounds great. We are still using QWidgets together with stylesheets. Sounds like this could be a better replacement for stylesheets. And if we can get a consistent look between QWidgets and QML we might even start using QML.
-
Hi,
Nice ! It's looking awesome !
One thing that you didn't mention is how it compares to the stylesheet QStyle. Does it also "break" the control style as it is not using the platform style ?@SGaist We haven't had much time yet to benchmark StyleKit against Qt Style Sheets. Most of our benchmarking so far has focused on start-up time for Qt Quick Controls, such as comparing a Fusion-like style implemented with StyleKit against the built-in Fusion style (on macOS and an i.MX 8). For our test app (with 150 checkboxes), we found that the StyleKit version takes about 250ms, while the built-in version takes about 210ms. But comparing performance against Qt Style Sheets is on our to-do list, and the results might even deserve a post of their own.
Does it also "break" the control style as it is not using the platform style ?
Not 100% sure what you mean by "control style" (the QtQuick.Controls import?), but yes, StyleKit will, by design, produce a style that looks exactly the same across all platforms. Even controls you don't explicitly style in your Style will simply use the default style, as mentioned in the post, rather than the platform's native style. If you'd rather have your app look native, you should import QtQuick.Controls, or one of the native styles directly (e.g. QtQuick.Controls.macOS).
-
@SGaist We haven't had much time yet to benchmark StyleKit against Qt Style Sheets. Most of our benchmarking so far has focused on start-up time for Qt Quick Controls, such as comparing a Fusion-like style implemented with StyleKit against the built-in Fusion style (on macOS and an i.MX 8). For our test app (with 150 checkboxes), we found that the StyleKit version takes about 250ms, while the built-in version takes about 210ms. But comparing performance against Qt Style Sheets is on our to-do list, and the results might even deserve a post of their own.
Does it also "break" the control style as it is not using the platform style ?
Not 100% sure what you mean by "control style" (the QtQuick.Controls import?), but yes, StyleKit will, by design, produce a style that looks exactly the same across all platforms. Even controls you don't explicitly style in your Style will simply use the default style, as mentioned in the post, rather than the platform's native style. If you'd rather have your app look native, you should import QtQuick.Controls, or one of the native styles directly (e.g. QtQuick.Controls.macOS).
@Richard-Moe-Gustavsen thanks for the details !
I saw the QStyle mention and thought it would be a dedicated style but I was wondering whether it would act like a proxy or be a full style. That question has been answered :-) -
Great work ! I have yet to try it (and won't do it for a serious project soon since we already have our own QQC custom style) but it seems it would ease the creation of custom style.
I'm not sure I agree with the disabled state excluding the highlighted one though. Does it mean that it won't be possible to differentiate disabled highlighted buttons from disabled non-highlighted buttons?
I use highlighted buttons for CTA (call to action) buttons, I still want a disabled one to be different from a normal button.I guess the intended way to do CTA is using variations now?
-
Great work ! I have yet to try it (and won't do it for a serious project soon since we already have our own QQC custom style) but it seems it would ease the creation of custom style.
I'm not sure I agree with the disabled state excluding the highlighted one though. Does it mean that it won't be possible to differentiate disabled highlighted buttons from disabled non-highlighted buttons?
I use highlighted buttons for CTA (call to action) buttons, I still want a disabled one to be different from a normal button.I guess the intended way to do CTA is using variations now?
@GrecKo According to the docs, a control "... can be highlighted in order to draw the user's attention towards it." But does it really make sense to draw attention to a disabled button or item delegate? We could allow it, but then it might come as a surprise that disabled controls also sometimes render as highlighted. That said, this is exactly the kind of thing we still have a chance to change while StyleKit is in Labs. If you think it's needed, feel free to file a report with a use-case, and we can take another look.
guess the intended way to do CTA is using variations now?
With StyleKit, yes!
-
According to the docs, a control "... can be highlighted in order to draw the user's attention towards it." But does it really make sense to draw attention to a disabled button or item delegate?
I'd say yes, the "Quick reply" button here in the forum is highlighted, one could easily imagine it being disabled when the message box is empty but still highlighted (with a less saturated text color or background maybe).
We could allow it, but then it might come as a surprise that disabled controls also sometimes render as highlighted.
If it is allowed and the precedence kept as is, I believe it will only render as highlighted if there's a
disabled.highlighted(or vice-versa) ControlStateStyle provided, that's quite explicit and intentional. A simpledisabledstyle will still be preferred over a simplehighlighted.If you think it's needed, feel free to file a report with a use-case
will do.
-
According to the docs, a control "... can be highlighted in order to draw the user's attention towards it." But does it really make sense to draw attention to a disabled button or item delegate?
I'd say yes, the "Quick reply" button here in the forum is highlighted, one could easily imagine it being disabled when the message box is empty but still highlighted (with a less saturated text color or background maybe).
We could allow it, but then it might come as a surprise that disabled controls also sometimes render as highlighted.
If it is allowed and the precedence kept as is, I believe it will only render as highlighted if there's a
disabled.highlighted(or vice-versa) ControlStateStyle provided, that's quite explicit and intentional. A simpledisabledstyle will still be preferred over a simplehighlighted.If you think it's needed, feel free to file a report with a use-case
will do.
An other use case that comes to mind is the table view. You have a row selected then open modal dialog: you still expect that the selection to be highlighted even if disabled. The color would be dimmed or even different but still shows the fact that something is selected.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
An other use case that comes to mind is the table view. You have a row selected then open modal dialog: you still expect that the selection to be highlighted even if disabled. The color would be dimmed or even different but still shows the fact that something is selected.
An other use case that comes to mind is the table view. You have a row selected then open modal dialog: you still expect that the selection to be highlighted even if disabled. The color would be dimmed or even different but still shows the fact that something is selected.
Personally, I'd consider that "Inactive" (defocussed) rather than "Disabled" (suppressed -> deselected), following the Active/Inactive/Disable concept at https://doc.qt.io/qt-6/qpalette.html#ColorGroup-enum. Are you thinking of a different meaning for "Disabled", @SGaist and @GrecKo?
As for dimming, the current pattern in Qt Quick Controls is to cover the whole window with a dimming overlay (https://doc.qt.io/qt-6/qml-qtquick-controls-popup.html#dim-prop), rather than change the state of individual elements of the window
-
@SGaist We haven't had much time yet to benchmark StyleKit against Qt Style Sheets. Most of our benchmarking so far has focused on start-up time for Qt Quick Controls, such as comparing a Fusion-like style implemented with StyleKit against the built-in Fusion style (on macOS and an i.MX 8). For our test app (with 150 checkboxes), we found that the StyleKit version takes about 250ms, while the built-in version takes about 210ms. But comparing performance against Qt Style Sheets is on our to-do list, and the results might even deserve a post of their own.
Does it also "break" the control style as it is not using the platform style ?
Not 100% sure what you mean by "control style" (the QtQuick.Controls import?), but yes, StyleKit will, by design, produce a style that looks exactly the same across all platforms. Even controls you don't explicitly style in your Style will simply use the default style, as mentioned in the post, rather than the platform's native style. If you'd rather have your app look native, you should import QtQuick.Controls, or one of the native styles directly (e.g. QtQuick.Controls.macOS).
@Richard-Moe-Gustavsen said in StyleKit:
comparing performance against Qt Style Sheets is on our to-do list
Other than performance, it's also worth comparing the usability of StyleKit vs. style sheets. I remember getting quite frustrated with style sheets before and had to fight hard to make things look exactly how I want.
I've yet to do a deep dive into StyleKit, but from a quick glance it seems more intuitive+flexible and less "surprising" than style sheets.
