Related to but necessarily a duplicate of T11558: kill plasma components in favour of qqc2-desktop-style. If we do T11558, we won't have to do this, but we can do this without having to do T11558.

feasible technical solutions at the moment are

• QQmlAbstractUrlInterceptor based solution: kinda error prone but easy to do
• configuration windows in a separate process: quite complicated and error prone, would take a year to do
• having config windows with the plasma style

a requitrement though is that the custom weird plasma styles from the store continue to work

I wouldn't be in favor of making config windows have the plasma style. In other respect they would match the desktop style (e.g. titlebar) so that would just be weird IMO.

One idea I've been throwing around recently is using the Plasma theme for apps too, by making the QStyle load Plasma theme SVGs. This would eliminate the potential problem of Plasma dialogs having a different appearance from apps, because all of them would be using the same theme in the first place. It would also allow a single theme to apply to the entire system, producing a major consistency win, and these newly-all-encompassing systemwide Plasma themes are share-able via GHNS, which is not currently possible using binary QStyle widgets themes. In so doing, the Breeze QStyle would be essentially transformed into a theme engine. Alternatively I suppose we would fork it into a new one, or write a new one.

If we did this, then we could port all of Plasma to use QQC2 rather than PlasmaComponents3 and load the Plasma style using qqc2-desktop-style or some other method, eventually winding up with only two UI libraries to maintain (QWidgets and QQC2+Kirigami, with no PC2 and PC3) and only one UI style to maintain (the Plasma style).

Thoughts?

Well Qstyle is had to make thus stuff like kvantumn. So this will help quite a bit

I am looking into what Qt calls "compile time selection" with Qt6. On the first look it looks exactly what we had with manually importing PlasmaComponents.

Consider:

import QtQuick
import QtQuick.Controls
Row {
    Button{text:"Button"}
    Button1{text:"Material"}
    Button2{text:"Universal"}
}
------
Button1.qml:
import QtQuick.Controls.Material
Button {}
----
Button2.qml
import QtQuick.Controls.Universal
Button {}

this results in:

A bit more interesting if if we also import Controls in addition to the style in Button1.qml:

import QtQuick.Controls
import QtQuick.Controls.Material
Button {}

Which has the same result

Even more interesting is that the same happens if Controls is imported after Material:

import QtQuick.Controls.Material
import QtQuick.Controls
Button {}

Now to the really interesting things can we influence the style also in a file we are including?
The main file looks this now:

import QtQuick
import QtQuick.Controls
import QtQuick.Controls.Fusion
Row {
    Button{text:"Button"}
    Button1{text:"SubFile"}
    Button2{text:"Universal"}
}

And Button1.qml reads now only:

import QtQuick.Controls
Button {}

import QtQuick
import QtQuick.Controls.Fusion
import QtQuick.Controls
Row {
    Button{text:"Button"}
    Button1{text:"SubFile"}
    Button2{text:"Universal"}
}

But we mostly use namespace imports for Quick Controls, so it surely doesn't work when using it in a namespace because now you would have QQC.Button and the plain Button comes from fusion? No, it still works:
Consider

import QtQuick
import QtQuick.Controls.Fusion
import QtQuick.Controls as QQC
Row {
    QQC.Button{text:"Button"}
    Button1{text:"SubFile"}
    Button2{text:"Universal"}
}

(Button1.qml unchanged for now from above with only importing Controls)

The same applies of course if we import it to the same namespace in both files. I.e. Button1.qml now reads

import QtQuick.Controls as QQC
QQC2.Button {}

import QtQuick.Controls as Controls
Controls.Button {}

\o/

So it looks to me that if we would import the Plasma style once in the root file before QtQuick.Controls we could happily use Components that make use of Controls.
Or the other way around for ConfigViews.

Of course that needs further testing with a with multiple engines, etc..

Very interesting. Great investigation! That could really be nice if this works out for our use case.

In T13256#246574, @ngraham wrote:

Very interesting. Great investigation! That could really be nice if this works out for our use case.

Finally, we can say "Qt6 will fix it™" :D