Clarification on Qt Backend / QStyle deprecation needed.

[kermitfrog]

Recently, I asked on the KDE-Discuss if there are any ongoing efforts to use Union for styling Slint. (I asked there instead of here because I thought anyone involved in this would be more active there, especially Union-Devs).
The discussion cast some doubts on whether I correctly understood what the deprecation of QStyle means.

My understanding was that QStyle and the Qt-Backend in Slint are interdependent and the deprecation meant there is no supported way left to have Slint render Widgets in a way that uses Qt for a native look.

But as was pointed out to me, that might not be true.

So, can I still (and for the foreseeable future) use the Qt-Backend to have native-looking Widgets? If so, how?

---

What I also wrote there:

What I can observe is this:

• Without setting a specific style, fluent is used
• When setting the style to native, fluent is used
• When setting the style to qt, the code won`t compile
• When setting cargo flags so that only the qt-backend is used and ..
• .. setting the style to qt, the code won`t compile
• .. either setting the style to native or not specifying it, cargo reports Error: No default Slint platform was selected, and no Slint platform was initialized

The errors when failing to compile are multiple occurences of these 2:

error[E0433]: cannot find `NativePalette` in `sp`
error[E0433]: cannot find `NativeScrollView` in `sp`

---

This is the discussion: https://discuss.kde.org/t/are-there-any-ongoing-efforts-to-bring-kirigami-union-to-slint/50466/8

[ogoffart]

The Qt backend is no longer enabled by default. When building slint you need to pass the --features=slint/backend-qt and then you get the Qt backend compiled in.

can I still (and for the foreseeable future) use the Qt-Backend to have native-looking Widgets?

Yes, you need to make sure that the qt backend is selected at compile time with the right feature, and then to select the Qt style which you did if you get cannot find NativePalette error.

[redstrate]

Hmm, then how does SLINT_NO_QT work then? Because I think that's only seen by the Qt backend, so is there a point in passing SLINT_NO_QT if its disabled by default?

[ogoffart]

indeed, SLINT_NO_QT is not so useful anymore.

(There could still be an app that want to enable qt in their default, and they could tell their user to use SLINT_NO_QT)

[kermitfrog]

Thanks, now it's working...

On the downside, I'm even more confused now because I'm sure I tried exactly that multiple times before without success.
No idea what I did wrong before.