Are there any ongoing efforts to bring Kirigami / Union to Slint?

Development
1

Some time ago I started writing an application. I wanted to use Rust and chose Slint as a UI toolkit because I like it’s syntax, etc. better than QMLs while looking close enough to a KDE application thanks to it’s Qt-Backend.
Then they dropped the Qt-Backend and since then I have been undecided how to proceeed (the fluent style is not an option – nor are hardcoded colors).

The best case for me would be to use Union to style Slint. I have looked a bit into it but believe that it’s too much work to do alone without completely neglecting the application I want to use it for.

So… did anyone here already start doing this? If so: is it already partially working?

If not, I guess I’m going to switch to the new Qt-Rust-Bridge and QML :confused:

2

Kirigami itself is a Qt Quick component set so it can’t really be used with any other toolkit.

Union, on the other hand, should be possible to apply to other style frameworks, however I would assume that at this point the focus is on QtWidgets and QtQuick.

Afterwards my guess is that other mainstream desktop toolkits like GTK or Iced would have higher priority Slint or other technologies which are mostly intended for embedded UI at this point.

3

What I’ll say is whataboutism, but I feel it’s worth noting that Slint suffers from accessibility issues last I checked. You can test that by using Orca on your own application, among other things. I’d like to know if they improved that.

4

they dropped the Qt-Backend

Sure about that? I see the last commit to the Qt backend was done by Olivier only 3 days ago:

https://github.com/slint-ui/slint/tree/master/internal/backends/qt

The Qt backend supports QStyle so Union should work.

Slint suffers from accessibility issues

Slint’s Qt backend supports QAccessible too:

https://github.com/slint-ui/slint/blob/master/internal/backends/qt/qt_accessible.rs

Other backends like Skia seem to be limited to accesskit which is indeed not as good as atspi on Linux (yet?):

https://github.com/slint-ui/slint/blob/master/internal/backends/winit/accesskit.rs

5

Yes, it would need to be ported to Slint. My initial thought was to port the components I need.. then others may join in to port additional components. Due to the similarities between QML and Slint I think it should be feasible to write tools to help with this. I’m not sure how much work all that would be though.

Union, on the other hand, should be possible to apply to other style frameworks, however I would assume that at this point the focus is on QtWidgets and QtQuick.

Afterwards my guess is that other mainstream desktop toolkits like GTK or Iced would have higher priority Slint or other technologies which are mostly intended for embedded UI at this point.

I’m not sure I would call Slint “mostly intended for embedded UI” anymore. They have been doing a lot to improve it for desktop lately. But it’s not as mature as Qt and some important features like modal dialogs are still not done.

But, yeah prioritizing GTK makes sense. I’m not sure about Iced - that would depend on usage statistics.

Interesting point. I know there are some accessibility features in Slint, but I haven’t tested them yet.

This is interesting.. they announced to deprecate it here and last time I tried, I could not sucessfully compile with the qt-backend enabled. But even if there is some minor work going on, there are still remaining bugs in the backend and to me it does not look like these will be fixed anytime soon…

6

Probably a lot.

It is definitely their focus and strength since they can easily out-compete others like Qt in terms of resource requirements.

True but far fewer developers are working on desktop features than would be necessary to be competitive with already established players.

I am sure they will eventually get there, as a growing ecosystem will also increase contributions to areas the core team can’t (yet) focus on.

Agreed, however with COSMIC giving a heavy push for Iced based apps this will become the third most widely used toolkit in a short time (if it isn’t already).

7

> This is interesting.. they announced to deprecate it here

That announcement is about deprecating their built-in styles and not about dropping their Qt backend.

https://github.com/slint-ui/slint/blob/master/README.md

NOTE: When Qt is installed on the system, the qt style becomes available, using Qt’s QStyle to achieve native looking widgets.

There CI/CD tests every commit in the cpp_cmake step against Qt:

https://github.com/slint-ui/slint/blob/master/.github/workflows/ci.yaml#L266

Otherwise there are the qtbridge-rust and CXX-Qt projects both maintained well too.

8

I see your point … this is getting confusing..

From the announcement:

What This Means for You
[..]

  • You can still select a specific style by name, or set it to native to keep the previous platform-adaptive behavior.
  • Non-Fluent styles will receive less updates and eventually be deprecated.

The first was true with 1.16 - I was able to switch to qt.. but since 1.17 qt-style does not work anymore. I’d attribute that to deprecation.

From the docs:

The Qt style uses Qt to render widgets. This style requires Qt to be installed on your system.

In my understanding this means that the style only works by using the Qt backend. As there is no way (I know of) to use the Qt backend without the style these seem interdependent.

NOTE: When Qt is installed on the system, the qt style becomes available, using Qt’s QStyle to achieve native looking widgets.

I think this is outdated.

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`

So from what I can see there seems to be no way to use a style based on Qt.

EDIT: the compile errors appear in the code generated by slint

9

In my understanding this means that the style only works by using the Qt backend. As there is no way (I know of) to use the Qt backend without the style these seem interdependent.

Yes. See also Qt Backend | Slint Docs

The Qt backend uses the Qt​:up_right_arrow: library to interact with the windowing system, for rendering, as well as widget style for a native look and feel.

And https://github.com/slint-ui/slint/blob/master/docs/install_qt.md

Do I need Qt to use Slint?

Short answer: No. Only if you want to use the Qt backend used for the native style.

Slint has two backends: GL and Qt. The GL backend uses the femtovg and winit crate for the rendering. The Qt backend uses Qt. In addition, the Qt backend provide the implementation for the native widget from the native style. Qt is only needed if you want native looking widgets. Otherwise, another style will be used for widget, which does not look native. In the future, we plan to have native backend using the native API, which will allow native widgets without using Qt.

The Slint styles are used for the winit backend while the Qt backend uses QStyle. See also https://github.com/slint-ui/slint/blob/master/internal/backends/qt/qt_widgets.rs

This module contains all the native Qt widget implementation that forwards to QStyle.

NOTE: When Qt is installed on the system, the qt style becomes available, using Qt’s QStyle to achieve native looking widgets.

I think this is outdated.

I don’t think so after looking at the docs, the code and the CI/CD.

When setting the style to qt, the code won`t compile

I suggest to create a bug report about that in there issue tracker and attach as much informations as possible. This error:

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

Sounds like your Slint was compiled without support for Qt since NativePalette is defined in https://github.com/slint-ui/slint/blob/master/internal/backends/qt/qt_widgets.rs

My wild guess would be that the with Slint generated code was generated with a Slint version which had the Qt backend enabled but now you try to use that generated code in a project with a Slint that not has the Qt backend enabled. I can also imagine, but didn’t check the code, that the generator actually allows to generate code for backends that are not enabled since the code generator not needs the backend but when you like to use the code you will need the backend. Such a setup would make sense for distributed work.

10

Well, you might be right…

My wild guess would be that the with Slint generated code was generated with a Slint version which had the Qt backend enabled but now you try to use that generated code in a project with a Slint that not has the Qt backend enabled [..]

The way I understand this, the code is generated by the slint-build crate, which has no documented flags that mention backends. So the generation would be affected by the CompilerConfiguration struct, which has a way to set the style, but not the backend. I already use this (together with explicitely setting the qt-backend flag on the slint crate) without success.

For now I started a discussion, asking for clarification. If the Slint-devs say it’s a bug, I’ll create a detailed report.

Thanks for the detailed research and answers :slight_smile:

11

I dont know anything about Slint but..

  • If Slint uses QStyles, it could technically use the Union widgets style (if it works seamlessly or not is another thing, as QStyles can be weird beasts)
  • If Slint has it’s own theme system, it could maybe read the Union CSS and construct it’s own style from same rules.

No idea how feasible the latter is though.

Union pretty much parses CSS and provides QtQuick and QtWidgets “outputs” applications can use to have same rules across the outputs. So if an output for Slint is made into Union (which is likely big task), it could happen. Same with GTK, Plasma styles, window decorations, etc etc.

12
  • If Slint uses QStyles [..]

It used to.. - but now it’s unclear - I hope on clarification from the devs soon.

  • If Slint has it’s own theme system[..]

Nothing I’d call that. You can change colors in the widgets directly and by that make new Widgets to override the defaults. But there is nothing I’m aware of where you just set rules that get applied everywhere yet.
The current styles are part of the main code base, which define their own colors (as read only values!) and override (some?) widgets.
There are 3rd party widgets with custom styles - these also define their own widgets.
I think they will add something like that eventually, but I’m not willing to wait for what might take years.

So, right now, creating custom Widgets that apply style rules seems the way to go.

Union pretty much parses CSS and provides QtQuick and QtWidgets “outputs” applications can use to have same rules across the outputs. So if an output for Slint is made into Union (which is likely big task), it could happen. [..]

I already looked into getting values from the Union-API. Maybe parsing the css directly would be easier for the task - at least easier to integrate with rust.
But the amount of work is whats stopping me and why I started the discussion. If there were others working on this, I might join in. But for me alone, this looks like too much work to do in my spare time.

13

@Sebastian_Sauer you were right! The qt-backend can still be used by enabling the flag for Slint and setting the style in build.rs to qt. And now it’s working.

The weird thing is: I am absolutely sure I tried exactly this multiple times before and got the compilation errors. No idea what went wrong before.

Summary

  • Thanks everyone for taking the time!
  • If you ever try to get Slint to use Qt for rendering and it doesn’t work - don’t give up and just try another day
  • I don’t have enough time to do it alone or now, but if anyone wants to work on better integration of Slint with KDE in the future, let me know :slight_smile:
14

Sounds like a great topic for a blog post at planet.kde.org :slight_smile:

15

Union’s styling model separates semantic design tokens from Qt Quick specifics, making an eventual Slint integration possible, but bridging them today requires manually translating tokens into Slint markup. Upstream development prioritizes QtWidgets and Qt Quick convergence, so there are no active upstream efforts or automated toolchains targeting Slint. For Rust projects needing native KDE/Breeze integration today, using the Qt-Rust bridge with QML/Kirigami provides full desktop theming out of the box, while adopting Slint requires maintaining custom styling rules and token exports independently.