Change Details

Various VDG and Plasma people had a meeting about how we want theming and styling in Plasma 6 to work. We tentatively decided that we want for theming across apps and Plasma to consume the same themes such that it's finally possible to have a consistent look and feel in both with one theme. There are a few ways we could do this: 1. **Make a QStyle that's able to consume Plasma themes and apply them to apps**. This would basically be replicating Kvantum, but hopefully better, and more supported, and faster, and less hacky. 2. **Create the concept of a new "universal theme" that uses CSS to define everything**, and then make a QStyle and QQC2 theme that's able to consume these themes and apply them to QWidgets apps, QQC2 desktop apps, and also Plasma, and port all of Plasma to use QQC2 and away from PlasmaComponents, deprecating SVG Plasma themes. The big advantage of #1 is that we could re-use the existing SVG Plasma themes, though a theme would need a lot of modification to add desktop-specific components to properly style a desktop app. The big advantage of #2 is that we would abandon SVG-based theming in Plasma, which is really fiddly and breakable and not well-liked by most KDE developers who have contact with it. Another conceivable advantage would be to allow this new universal CSS-based theme easily generate GTK themes as well, which are also CSS-based. Regardless of which option is chosen, general advantages of either approach are: - Unified styling between Plasma and desktop apps becomes easily possible - SVG or CSS-based styles are easier to create and modify than C++-based QStyles are - Can use the GHNS system to distribute and get themes for apps as well - Could drop PlasmaComponents stuff entirely in favor of using upstream QQC2 controls with the new theming system applied to them - Could end up reducing the user demand for Kvantum, which serves the same purpose by being an application theming engine you load themes into

Various VDG and Plasma people had a meeting about how we want theming and styling in Plasma 6 to work. We tentatively decided that we want for theming across apps and Plasma to consume the same themes such that it's finally possible to have a consistent look and feel in both with one theme. There are a few ways we could do this: 1. **Make a QStyle that's able to consume Plasma themes and apply them to apps**. This would basically be replicating Kvantum, but hopefully better, and more supported, and faster, and less hacky. 2. **Create the concept of a new "universal theme" that uses CSS to define everything**, and then make a QStyle and QQC2 theme that's able to consume these themes and apply them to QWidgets apps, QQC2 desktop apps, and also Plasma, and port all of Plasma to use QQC2 and away from PlasmaComponents, deprecating SVG Plasma themes. The big advantage of #1 is that we could re-use the existing SVG Plasma themes, though a theme would need a lot of modification to add desktop-specific components to properly style a desktop app. The big advantage of #2 is that we would abandon SVG-based theming in Plasma, which is really fiddly and breakable and not well-liked by most KDE developers who have contact with it. Another conceivable advantage would be to allow this new universal CSS-based theme easily generate GTK themes as well, which are also CSS-based. Regardless of which option is chosen, general advantages of either approach are: - Unified styling between Plasma and desktop apps becomes easily possible - SVG or CSS-based styles are easier to create and modify than C++-based QStyles are - Can use the GHNS system to distribute and get themes for apps as well - Could drop PlasmaComponents stuff entirely in favor of using upstream QQC2 controls with the new theming system applied to them - These themes would have no code in them, just styling. No more possibility for buggy themes to crash apps; all such bugs would be limited to the engine applying the theme, not the theme itself - Could end up reducing the user demand for Kvantum, which serves the same purpose by being an application theming engine you load themes into

Various VDG and Plasma people had a meeting about how we want theming and styling in Plasma 6 to work. We tentatively decided that we want for theming across apps and Plasma to consume the same themes such that it's finally possible to have a consistent look and feel in both with one theme. There are a few ways we could do this: 1. **Make a QStyle that's able to consume Plasma themes and apply them to apps**. This would basically be replicating Kvantum, but hopefully better, and more supported, and faster, and less hacky. 2. **Create the concept of a new "universal theme" that uses CSS to define everything**, and then make a QStyle and QQC2 theme that's able to consume these themes and apply them to QWidgets apps, QQC2 desktop apps, and also Plasma, and port all of Plasma to use QQC2 and away from PlasmaComponents, deprecating SVG Plasma themes. The big advantage of #1 is that we could re-use the existing SVG Plasma themes, though a theme would need a lot of modification to add desktop-specific components to properly style a desktop app. The big advantage of #2 is that we would abandon SVG-based theming in Plasma, which is really fiddly and breakable and not well-liked by most KDE developers who have contact with it. Another conceivable advantage would be to allow this new universal CSS-based theme easily generate GTK themes as well, which are also CSS-based. Regardless of which option is chosen, general advantages of either approach are: - Unified styling between Plasma and desktop apps becomes easily possible - SVG or CSS-based styles are easier to create and modify than C++-based QStyles are - Can use the GHNS system to distribute and get themes for apps as well - Could drop PlasmaComponents stuff entirely in favor of using upstream QQC2 controls with the new theming system applied to them - These themes would have no code in them, just styling. No more possibility for buggy themes to crash apps; all such bugs would be limited to the engine applying the theme, not the theme itself - Could end up reducing the user demand for Kvantum, which serves the same purpose by being an application theming engine you load themes into