Re: Approval request for feature idea
Hello Sven. Thank you for the clarification. I tried to make a style plugin since my last message, and I see what you mean about stylesheets not being styles. I've been trying very hard to find a way to convert between the two but it hasn't worked out. I'm going to try to make my own implementation of the CSS parser idea that you referenced in your other email, and I'll report back to this thread once I have a prototype. I'll try to build on top of the QSS syntax, which I originally thought was the reason everyone seemed against stylesheets but now I know that's not the case. Again, thanks for all your help! On Wed, Jun 1, 2022 at 4:44 PM Sven Brauch wrote: > Hi, > > On 6/1/22 20:41, samuel ammonius wrote: > > However, I still don't see the point of avoiding QSS because it seems to > > be able to do everything CSS can (besides transformations, which are the > > only difference that I've been able to find so far). > > Sorry but then you're not looking very hard. Look at e.g. [1]. > > Just from a quick scroll-through, I find a lot of stuff QSS has never > heard about, such as animations, box-shadow, caret-color, clipping, > filter, float, advanced font options, text transform, text shadow, media > queries, blend mode, overflow, perspective, transitions, n-th-child > selectors, in general half the selectors, all CSS functions, > before/after content, etc etc etc. > > But that's not even the problem. The problem is that QSS is not a style > by itself, it is applied *on top of* a style such as Fusion, and does > *not* give you full control over that style. > > So what do you even want to achieve? > > Do you want a fully customizable style? QSS isn't, it's not even *a* > style to begin with. > > Do you want to apply some customization while preserving the base looks > of whatever style the user has configured? Then QSS is a nice thing but > unless you limit yourself to really basic stuff (mainly colors) some > widgets will look weird or broken in some base styles, or in some > applications. They might even break with colors alone, simply from the > fact that a style sheet is set at all. > > I suggest we stop discussing this here at this point, I don't think it's > very productive. I'd recommend you try to make a complete style changing > appearance of all widgets (especially the more funky stuff: scrollbars, > checkable combo boxes, progress bars, tool buttons with dropdowns, > checkable menu items with icons, tree view items, ...) as you want them > to look like with QSS, and open a few complicated applications (krita, > dolphin, kdevelop, gwenview, the KDE file dialogs) with that style. I > recommend a dark style, it tends to make problems more obvious. Try to > make it perfect, like you'd actually want it to look like, not a > prototype. I hope this experience helps you understand the concerns > raised here. And if not -- well, maybe people here are wrong and this > idea will fly after all ;) > > Greetings, > Sven > > _ > [1] https://www.w3schools.com/cssref/default.asp >
Re: Approval request for feature idea
Hi, On 6/1/22 20:41, samuel ammonius wrote: However, I still don't see the point of avoiding QSS because it seems to be able to do everything CSS can (besides transformations, which are the only difference that I've been able to find so far). Sorry but then you're not looking very hard. Look at e.g. [1]. Just from a quick scroll-through, I find a lot of stuff QSS has never heard about, such as animations, box-shadow, caret-color, clipping, filter, float, advanced font options, text transform, text shadow, media queries, blend mode, overflow, perspective, transitions, n-th-child selectors, in general half the selectors, all CSS functions, before/after content, etc etc etc. But that's not even the problem. The problem is that QSS is not a style by itself, it is applied *on top of* a style such as Fusion, and does *not* give you full control over that style. So what do you even want to achieve? Do you want a fully customizable style? QSS isn't, it's not even *a* style to begin with. Do you want to apply some customization while preserving the base looks of whatever style the user has configured? Then QSS is a nice thing but unless you limit yourself to really basic stuff (mainly colors) some widgets will look weird or broken in some base styles, or in some applications. They might even break with colors alone, simply from the fact that a style sheet is set at all. I suggest we stop discussing this here at this point, I don't think it's very productive. I'd recommend you try to make a complete style changing appearance of all widgets (especially the more funky stuff: scrollbars, checkable combo boxes, progress bars, tool buttons with dropdowns, checkable menu items with icons, tree view items, ...) as you want them to look like with QSS, and open a few complicated applications (krita, dolphin, kdevelop, gwenview, the KDE file dialogs) with that style. I recommend a dark style, it tends to make problems more obvious. Try to make it perfect, like you'd actually want it to look like, not a prototype. I hope this experience helps you understand the concerns raised here. And if not -- well, maybe people here are wrong and this idea will fly after all ;) Greetings, Sven _ [1] https://www.w3schools.com/cssref/default.asp OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Approval request for feature idea
This sounds amazing! However, I still don't see the point of avoiding QSS because it seems to be able to do everything CSS can (besides transformations, which are the only difference that I've been able to find so far).
Re: Approval request for feature idea
This sounds amazing! However, I still don't see the point of avoiding QSS because it seems to be able to do everything CSS can (besides transformations, which are the only difference that I've been able to find so far). On Wed, Jun 1, 2022 at 1:25 AM Nate Graham wrote: > Hello Samuel, > > There's an idea for the future of theming in Plasma 6 that would use CSS > to define a "universal theme" that would then be consumed by our QQC2, > Plasma, and GTK theming to keep them all in sync automatically. See > https://phabricator.kde.org/T13467. This is one of the options presented > there, but to my knowledge the only one with a prototype implementation, > made by Arjen Hiemstra (CCd). If you're interested in pursuing this, you > might want to get in touch with him about it. > > Nate >
Re: Approval request for feature idea
Hello Samuel, There's an idea for the future of theming in Plasma 6 that would use CSS to define a "universal theme" that would then be consumed by our QQC2, Plasma, and GTK theming to keep them all in sync automatically. See https://phabricator.kde.org/T13467. This is one of the options presented there, but to my knowledge the only one with a prototype implementation, made by Arjen Hiemstra (CCd). If you're interested in pursuing this, you might want to get in touch with him about it. Nate
Re: Fwd: Approval request for feature idea
I also found this: https://github.com/Alexhuszagh/BreezeStyleSheets#gallery On Mon, May 30, 2022 at 4:32 PM Sven Brauch wrote: > Hi, > > On 5/30/22 20:37, samuel ammonius wrote: > > I've worked with regular CSS and I'm sure that stylesheets offer just as > > many customization options as things like QtCurve or QStylePlugins. The > > reason that it may not seem this way is because Qt didn't document > > regular CSS syntax in the documentation for stylesheets. > > No, the reason is that Qt's CSS has absolutely nothing to do with the > regular CSS known from browsers. It's a proxy style which tweaks how a > base style (e.g. Fusion or Breeze) draws elements on the screen, by e.g. > modifying the palette and then forwarding the draw call to the base > style. It implements maybe 1% of the CSS stuff a modern browser can do, > and that's a favourable estimate. And not even all of that will work as > expected in all cases. For details, see [1]. > > That this proxy style's behaviour can be configured using a CSS-like > syntax is coincidental, or, well, intentionally made that way for ease > of use. But: this is not the CSS you know or expect. > > > I can't verify that stylesheets can do everything that a style plugin > > can do > > They can't. Regular CSS 3 in Firefox is probably pretty close, > practically speaking, but Qt's CSS, not so much. > > > but I know for sure that Breeze can be made using a qstylesheet > > Where did you get this information? This is certainly not the case. Just > try to make e.g. the animated fades in Breeze using Qt's CSS and Fusion > as the base style and you will immediately discover that it's not possible. > > Greetings, > Sven > > _ > [1] > > https://code.woboq.org/qt5/qtbase/src/widgets/styles/qstylesheetstyle.cpp.html >
Re: Fwd: Approval request for feature idea
https://doc.qt.io/qt-5/stylesheet-reference.html#:~:text=widget%2Danimation%2Dduration* Wouldn't this allow animated fades? On Mon, May 30, 2022 at 4:32 PM Sven Brauch wrote: > Hi, > > On 5/30/22 20:37, samuel ammonius wrote: > > I've worked with regular CSS and I'm sure that stylesheets offer just as > > many customization options as things like QtCurve or QStylePlugins. The > > reason that it may not seem this way is because Qt didn't document > > regular CSS syntax in the documentation for stylesheets. > > No, the reason is that Qt's CSS has absolutely nothing to do with the > regular CSS known from browsers. It's a proxy style which tweaks how a > base style (e.g. Fusion or Breeze) draws elements on the screen, by e.g. > modifying the palette and then forwarding the draw call to the base > style. It implements maybe 1% of the CSS stuff a modern browser can do, > and that's a favourable estimate. And not even all of that will work as > expected in all cases. For details, see [1]. > > That this proxy style's behaviour can be configured using a CSS-like > syntax is coincidental, or, well, intentionally made that way for ease > of use. But: this is not the CSS you know or expect. > > > I can't verify that stylesheets can do everything that a style plugin > > can do > > They can't. Regular CSS 3 in Firefox is probably pretty close, > practically speaking, but Qt's CSS, not so much. > > > but I know for sure that Breeze can be made using a qstylesheet > > Where did you get this information? This is certainly not the case. Just > try to make e.g. the animated fades in Breeze using Qt's CSS and Fusion > as the base style and you will immediately discover that it's not possible. > > Greetings, > Sven > > _ > [1] > > https://code.woboq.org/qt5/qtbase/src/widgets/styles/qstylesheetstyle.cpp.html >
Re: Fwd: Approval request for feature idea
Hi, On 5/30/22 20:37, samuel ammonius wrote: I've worked with regular CSS and I'm sure that stylesheets offer just as many customization options as things like QtCurve or QStylePlugins. The reason that it may not seem this way is because Qt didn't document regular CSS syntax in the documentation for stylesheets. No, the reason is that Qt's CSS has absolutely nothing to do with the regular CSS known from browsers. It's a proxy style which tweaks how a base style (e.g. Fusion or Breeze) draws elements on the screen, by e.g. modifying the palette and then forwarding the draw call to the base style. It implements maybe 1% of the CSS stuff a modern browser can do, and that's a favourable estimate. And not even all of that will work as expected in all cases. For details, see [1]. That this proxy style's behaviour can be configured using a CSS-like syntax is coincidental, or, well, intentionally made that way for ease of use. But: this is not the CSS you know or expect. I can't verify that stylesheets can do everything that a style plugin can do They can't. Regular CSS 3 in Firefox is probably pretty close, practically speaking, but Qt's CSS, not so much. but I know for sure that Breeze can be made using a qstylesheet Where did you get this information? This is certainly not the case. Just try to make e.g. the animated fades in Breeze using Qt's CSS and Fusion as the base style and you will immediately discover that it's not possible. Greetings, Sven _ [1] https://code.woboq.org/qt5/qtbase/src/widgets/styles/qstylesheetstyle.cpp.html OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Fwd: Approval request for feature idea
I've worked with regular CSS and I'm sure that stylesheets offer just as many customization options as things like QtCurve or QStylePlugins. The reason that it may not seem this way is because Qt didn't document regular CSS syntax in the documentation for stylesheets. I can't verify that stylesheets can do everything that a style plugin can do, but I know for sure that Breeze can be made using a qstylesheet so there shouldn't be any reason to say that stylesheets don't have enough features to be added to KDE. On Mon, May 30, 2022 at 3:51 PM Sven Brauch wrote: > Hi, > > On 5/30/22 19:52, samuel ammonius wrote: > > Adding this feature won't make the C++ styles disappear. It will only > > make it possible for users who don't know how to make a style plugin in > > C++ to make their own styles > > the problem is that the Qt stylesheets are pretty bad at that. The > customization options they provide are limited, work in unexpected ways, > and sometimes look flat-out buggy, especially if applications have their > own widgets or drawing code or if the stylesheet is applied on top of an > unusual base style. > > They are fine for coloring a combo box or line edit in red if the input > is invalid, but they are not a useful user-configurable theme engine. > > I do see the value in the feature you envision, but IMO it needs to > happen in the form of something like the QtCurve style, which does its > painting in a way that is directly intended to be customized. > Customization needs to be offered by the style; it cannot be kludged on > top of the style with the QCssStyle proxy style, at least not in its > current form (but probably not at all). I suggest looking into something > like this if you'd like to provide user-customizable styles. > > Greetings, > Sven >
Re: Fwd: Approval request for feature idea
Hi, On 5/30/22 19:52, samuel ammonius wrote: Adding this feature won't make the C++ styles disappear. It will only make it possible for users who don't know how to make a style plugin in C++ to make their own styles the problem is that the Qt stylesheets are pretty bad at that. The customization options they provide are limited, work in unexpected ways, and sometimes look flat-out buggy, especially if applications have their own widgets or drawing code or if the stylesheet is applied on top of an unusual base style. They are fine for coloring a combo box or line edit in red if the input is invalid, but they are not a useful user-configurable theme engine. I do see the value in the feature you envision, but IMO it needs to happen in the form of something like the QtCurve style, which does its painting in a way that is directly intended to be customized. Customization needs to be offered by the style; it cannot be kludged on top of the style with the QCssStyle proxy style, at least not in its current form (but probably not at all). I suggest looking into something like this if you'd like to provide user-customizable styles. Greetings, Sven OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Fwd: Approval request for feature idea
Adding this feature won't make the C++ styles disappear. It will only make it possible for users who don't know how to make a style plugin in C++ to make their own styles, while other users get to choose between using C++ styles for their performance or using stylesheet styles that may look better to that user. Besides the performance cost, I didn't understand most of the items on that chart, but I think the choice to use this feature should be available for users regardless of the weaknesses QStylesheets may have, because the existence of the feature won't affect any other choices. On another note: the performance cost of QStylesheets can be dodged by making the Style plugin only parse the stylesheet once, and then return the resulting style to all applications without needing to parse it again.
Re: Approval request for feature idea
On Montag, 30. Mai 2022 02:33:56 CEST samuel ammonius wrote: > I wanted to submit a feature for kde that would allow users to set the > application style to a qstylesheet file (style.qss for example). This > feature would greatly increase the amount of themes available for KDE, make > it possible for users to tweak themes themselves, and make it easier to > include custom icons/images with themes if necessary by using the url() > function in the stylesheet. It would also make it easier for experienced > developers who can make KDE themes in C++ to make multiple, more complex > themes in less time. The feature would also be very easy to make and would > probably take less than 1 Megabyte of total storage. > > I originally wanted to submit this as a project in Google summer of code, > but I missed the deadline for applying. Who should I contact to get > approval for this before submitting a pull request? https://www.kdab.com/say-no-to-qt-style-sheets/ -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Approval request for feature idea
I wanted to submit a feature for kde that would allow users to set the application style to a qstylesheet file (style.qss for example). This feature would greatly increase the amount of themes available for KDE, make it possible for users to tweak themes themselves, and make it easier to include custom icons/images with themes if necessary by using the url() function in the stylesheet. It would also make it easier for experienced developers who can make KDE themes in C++ to make multiple, more complex themes in less time. The feature would also be very easy to make and would probably take less than 1 Megabyte of total storage. I originally wanted to submit this as a project in Google summer of code, but I missed the deadline for applying. Who should I contact to get approval for this before submitting a pull request?
