Le lundi, avril 12, 2021 10:20 PM, Nate Graham <n...@kde.org> a écrit :
> [explicitly CCing Noah] > > On 3/10/21 8:52 AM, Marco Martin wrote: > > > On Wed, Mar 10, 2021 at 4:09 PM Nate Graham n...@kde.org wrote: > > > > > People go off an do their own thing in an un-coordinated manner when > > > there is a significant problem that's not being solved, that problem has > > > existed for a while without being addressed, and there is no clear > > > direction or centrally coordinated plan for solving it. > > > > yes, that's exactly what happened and is a good warning for the future. > > Also a good signal that we should start thinking and actually doing > > something > > wrt a good theming story, which we clearly don't have. > > To me, the most promising approach was the quick prototype Arjen did > > back at akademy > > https://invent.kde.org/ahiemstra/qtunifiedstyle > > whether is something realistic to turn is something actually useful or > > not remains to be seen. > > We do have a ton of things to do otherwise, so is not easy to find > > time for this, but is becoming > > more and more important > > Based on other random conversations since this email thread petered out, > it seems like we're going to end up considering qqc2-breeze-style to be > a successful yet temporary stopgap solution from PlaMo, and continue > using the qqc2-desktop-style theme bridge we currently have--fixing bugs > and improving performance as needed--until we re-do and unify our whole > theming system. > > On that subject, have we done any further brainstorming? I remember > being fairly impressed with Arjen's prototype as well. I love the idea > of finally being able to theme everything consistently, and also the > possibility of using CSS which is simple, easily writable, and easily > readable in a diff view without losing your mind :) > > As I understand it, here's the latest proposal: > > 1. We make a universal theme of some sort (using CSS, QML, or something > else; exact format TBD) > > 2. We make a QStyle that is essentially a Kvantum-style theming engine > that consumes the universal theme and applies it to Widgets-based > apps > > 3. We make a QQC2 style that consumes the universal theme and applies it > to QtQuick software, including (optionally) Plasma, without going > through QPainter or the QStyle at all > > 4. We keep the existing Plasma QQC2 style that knows how to consume > existing SVG-based Plasma themes, for compatibility's sake > > 5. We add a user-facing setting for apps to allow people to choose > whether to have: > - Their apps use the universal theme > - Their apps use a different QStyle, such as Lightly or Kvantum > 6. We add a user-facing setting for Plasma to allow people to choose > whether to have: > - Plasma use the same universal style as their apps > - Plasma use a different universal style from the one being used for > their apps > > - Plasma use an SVG-based Plasma 5 theme, which we deprecate in > Plasma 6 but continue to support > > 7. In Plasma 7, we sunset support for SVG-based Plasma themes as well as > generic QStyles (including Kvantum!) and only support the new > universal theme--whatever it is we come up with > > Am I representing everything accurately, to the best of everyone else's > memory? > > Nate > And I still have the same worries as before. Building a universal theming system will takes **years** to make in a way that won't feel like a big regression for our users. At least for the QML engine, some part like configuring the paddings, margins, borders will be relatively easy since those can be mapped to QQC2 easily. That will be more complicated is everything that has to do with animations Just an example, implementing ripple effects, for example, require js in HTML, custom shaders in QML and custom c++ code for the animation in QtWidgets. Trying to abstract that will be hard but not impossible. Another example of a hard part will be the scrollbars. Currently just looking at the different qstyle installed on my machine, I can see many completely behaviors and button placements. Again it's not impossible to solve by figuring out a good abstraction and adding tons of options. But at the end we will end up with a list of configuration options that are passed to the engine and two implementations that should be able to handle **all** the options required to implement the existing themes. here for example to support an oxygen style scrollbar (written in scss) scrollbar { border-width: 0; item { color: ... } top-buttons { move-top: { display: true; icon-name: .... background: none; } move-bottom: { display: false } } item-background { box-shadow: inner 2px 2px grey; border-radius: 2px background-color: ... &::hover { background-color: ... } } item { margin: 2px width: calc(100% - 4px); background-color: &::hover { background-color: ... box-shadow: outer 2px 2px blue; } } bottom-buttons { move-top: { display: true; icon-name: .... background: none; } move-top: { display: true; icon-name: .... background: none; } } } This already seems like a lot of rules and I probably forgot many more... A solution to reduce the number of rules to implement would be to allow the engine to accept textures provided by svg files. But that brings us back to the problem of it being too slow for the pinephone and require some hacks to pass some parameters to the theme (for example for the margins or the colors). Allowing to ship QQC2 themes with QStyles themes sounds a lot easier to implement compared to that. And sure it won't be perfect but the unified style also won't be perfect anytime soon. Anyway, if someone wants to invest a lot of time in creating the unified theme, I won't stop them and I would happy to be proved wrong about my worries. But until then I will use the breeze qqc2 style on the desktop too because it's smoother and less buggy than the desktop style. I would even argue that we should ship it with our QML applications in Android. Regards, Carl
