Changing the Default Style in Slint — Deprecating Native-Looking Styles

[ogoffart]

Discussion thread for the blog post Changing the Default Style in Slint — Deprecating Native-Looking Styles

[RolansK]

Sounds like a positive change to me. As someone currently building an electron app but keeping an eye on Slint for future migration, I'm all for it if it means faster iteration. And for my app, I am keeping the styling consistent across platforms, indeed like the blog post mentions

[abghim]

I'm supportive of this change as well. Slint's biggest pain point to other frameworks might be the lack of mature components, and if the developers and the community can iterate faster on maintaining a more abundant set of components, that would no longer hold Slint back.

[michalfita]

While decision is understandable, makes sense and surprises it happen only now, I wonder if it's betting the right horse style wise. Mimicking Windows in 2026 might be not right bet, but it'd be right to assume you have some statistics what your customers still use most frequently (aside embedded). Maybe instead of deprecating, other style shall be handled by the community with own maintainers?

[huxeon]

I think it's ok. For me, most of the time, I only use one style. I think a mature, well maintained default one is better than some less maintained ones. If doing this can make the development faster and more mature, it's a good idea.

[moolight-seashell]

That sounds perfect to me, other toolkits that adapt to the system style have always caused quite a few problems.

And I think we can say without much hesitation (especially given the ubiquity of webs / Electron / Tauri apps ) that the vast majority of designers want their apps to look identical regardless of the platform.

On top of that, I think most serious graphics applications will want to manage their own styles entirely, without ever using any default styles (except perhaps for extensive pre-made widget libraries, although we will likely still want to manage basic theme settings such as colors).

So, in summary, for me, removing the native themes eliminates what is, in most cases, more of a problem than a desired behavior.

[rsov]

Would be nice if the native styles could be extracted into a "theme" plugin/extension

That way community can maintain them or create and share new styles

[hyuri]

Reasonable decision, but going with Fluent? It's the worst one. Feeling at home on Windows is not a positive. I would rather have a completely custom design than going with the Windows one.

[tronical]

I'd also rather have a completely custom design, but that's also ... a fair amount of work :-). So this is a compromise. Clearly a matter of taste, but it's also clear that a lot of effort was put into Fluent's design.

[JoeJoeTV]

Hmm, one of the reasons I was using slint, was that it also supported Qt-style widgets and the QT backend which looked more at home for professional-style software which did not really need that much fancy glazing, at least on Windows.

For some parts of the design, I'm also not really happy with the Fluent design. One example would be the menu (bar), which currently is way to in my opinion and is too separated from the top of the window. The menus seem to be floating bubbles instead of in a menu bar and take too much space. This is one point, where I would really want mentus like with "classic" Windows or Qt apps, that are there, but mostly get out of the way until you need them.

I also think for a productivity app, some of the elements are too big, similar to the Adwaita theme used by GNOME applications on Linux. Especially in comparison to what I currently have using the Qt style and backend.

Furthermore, at least I like applications that fit in to my system, so applications that adapt to the theme or color preference and don't look completely different to the other applications that are already included with the operating system. With the Qt style, this was already pretty close and I would say close enough, like with other Qt applications I have used and am using, since I can set up Qt to match the system theme mostly.

I definitely see at least some of the reason why this was done and it does make sense that not having 5 different implementations of widgets makes development easier, but I still think that some things or usecases are lost with this.

Maybe allowing more theme-customization with the future single theme would help mitigate some of these issues by letting the application developer choose to e.g. have smaller buttons accross the application or a small menu bar like with other styles or less/more rounding for some UI elements.
And if possible, some more integration with things like themes on Linux could also help making Slint applications fit in more (maybe there could be something like theme support for Slint, if the application developer wants this, like how GTK themes are used by people).

[kermitfrog]

Well.. I have mixed feelings about this decision.
I can absolutely understand it from the business/developer-time perspective. But it also means that I have to re-evaluate if I keep using slint or not :(

My reasons to try it were that I wanted to use Rust and was not happy with some things about QML - but still wanted a UI-Toolkit that can integrate reasonably well with KDE.
Slint was the only option I could find.

At the same time, the ecosystem has evolved. Many modern applications no longer strictly follow native platform styles and instead adopt a consistent cross-platform design.

Yes, and I really hate this trend!
As a user I want applications to respect my decisions. Like which fonts I prefer and how much contrast I want when reading text. Of course it's easier to maintain one design everywhere, but applications that integrate are better.
As for fluent: it uses colors that have too much contrast (in dark mode), which makes it unaccaptable to me. Other users might dislike other things about it. That's why every good DE allows system wide customization, which good apps should respect.

Even platform vendors such as Microsoft are moving in this direction.

As far as I can tell, Microsoft has failed to have a consistent style in their own applications for more than a decade - I'd rather say they have at least 4 styles. And I wouldn't consider them as an example on how to do good UIs anyway..

That's why we're also investing in making it easier to create and maintain custom styles.

The important thing is that those styles can read system settings. Besides applying the configured scaling (which is not a problem with fluent), the absolute minimum I expect from an UI Toolkit is to base it's colors on my system theme and use the fonts I have configured. If it's possible to make a theme that will adjust to user settings, I might keep using slint.

I wonder if KDE's union project could be used to style slint.

[tronical]

Thanks for the detailed answer. You have certainly valid points :). I particularly agree on picking up system settings. You might be delighted to see Olivier's recent PR: #11229

[kermitfrog]

That is definitely first a step in the right direction :)
I don't think there is a desktop independent way to read the other colors though.

[moolight-seashell]

I also think for a productivity app, some of the elements are too big, similar to the Adwaita theme used by GNOME applications on Linux. Especially in comparison to what I currently have using the Qt style and backend.

As for the size issue, I wouldn’t say current frameworks are “outdated”, but rather that they often prioritize density over usability.

Modern UX research tends to favor more spacing and larger interactive elements, for several reasons: reducing cognitive load, improving decision time (Hick’s Law), making interactions easier (Fitts’s Law), and clarifying structure through spacing (Gestalt principles).
We can also look at design standards such as Google’s Material Design or Apple’s standards, which also support this approach.

That said, I do think this depends a lot on the context. For productivity tools, higher density can still be valuable, especially for experienced users.

Yes, and I really hate this trend!
As a user I want applications to respect my decisions. Like which fonts I prefer and how much contrast I want when reading text.

Regarding user preferences, I mostly agree with the concern. Users should absolutely have control over things like fonts, contrast, and general appearance.

The issue, in my opinion, is more about how this is handled in the Linux ecosystem. With toolkits like Qt and GTK, theming is largely decentralized and inconsistently applied, which often leads to broken or incoherent results (e.g. incorrect colors, unreadable text, etc.).
( And we can also add the desktop environment theme (window decorations), which might be different from everything else )

Ideally, this would be handled through a more unified system-level approach (apis) rather than relying on each toolkit to interpret settings differently.

In the absence of such a standard, it can make sense for applications to manage their own styling more explicitly, while still respecting key user preferences like light/dark mode or accent colors. ( especially if it helps avoid broken uis, and make the tests more consistent and predictable )

[JoeJoeTV]

As for the size issue, I wouldn’t say current frameworks are “outdated”, but rather that they often prioritize density over usability.

Modern UX research tends to favor more spacing and larger interactive elements, for several reasons: reducing cognitive load, improving decision time (Hick’s Law), making interactions easier (Fitts’s Law), and clarifying structure through spacing (Gestalt principles). We can also look at design standards such as Google’s Material Design or Apple’s standards, which also support this approach.

That said, I do think this depends a lot on the context. For productivity tools, higher density can still be valuable, especially for experienced users.

I definitely see the advantage of having bigger buttons for e.g. touchscreens or as an accessibility option, but many of the applications using e.g. libAdwaita don't seem to me as if the Button size would help a lot and especially if I compare a proof-of-concept slint app I wrote on Windows using Qt and Fluent, it looks way to bloated and elements look too separated in the Fluent style, like it doesn't fit together.
I think larger buttons than the Qt version on Windows 11 are not bad, but Fluent is too excessive with this.
It seems like I have to make the Button text bigger to properly fit the button, but this would completely ruin the scaling of the application's UI elements.

I can't speak about Apple's designs a lot, but for Material, in my opinion, it has gotten worse in the newer versions. I liked the rounded, but not too rounded buttons in previous Material versions, but the completely round/pill-shaped design is very much too rounded in my opinion.
This is also why some flutter desktop applications just feel off to me and why I like applications that follow my system theme on Linux (for me this would be the Linux Mint GTK theme), since they include slight rounding, while it not disrupting the general shape of elements.

The issue, in my opinion, is more about how this is handled in the Linux ecosystem. With toolkits like Qt and GTK, theming is largely decentralized and inconsistently applied, which often leads to broken or incoherent results (e.g. incorrect colors, unreadable text, etc.). ( And we can also add the desktop environment theme (window decorations), which might be different from everything else )

Ideally, this would be handled through a more unified system-level approach (apis) rather than relying on each toolkit to interpret settings differently.

I definitely think some kind of theme standard, which is maybe more limited that e.g. GTK CSS themes or QT styles while still providing more options that just light/dark and the accent color would be a huge boon for GUI applications on Linux at least.
It could make it much easier for applications on different UI toolkits to at least fit in with each other.
There is an entire Wiki page on the Arch Wiki for making different GUI toolkits look the same or similar, so reducing the burden for both users and developers would be great.

Slint could theoretically start with such an interface, which provides enough control while not being CSS.

In the absence of such a standard, it can make sense for applications to manage their own styling more explicitly, while still respecting key user preferences like light/dark mode or accent colors. ( especially if it helps avoid broken uis, and make the tests more consistent and predictable )

I have to agree with kermitfrog, that I very much dislikte the trend of applications doing a completely custom styling with no (easy) option to make it fit into the system.
This is especially true with e.g. Electron/Web-Desktop or Flutter apps.

[John0x]

I think this is the right direction, but choosing fluent design and calling it clean and modern feels pretty outdated, to be honest 😄
Would have preferred if there was a headless base (like base-ui) and an actually modern and clean custom style as the default. Pretty much like modern ui design actually works.

[jsprog]

I support your idea for the base-ui and custom styling but with the capability to override the styles live/reactively (with the optional support for animated switching of colors!).
The current themes are restrictive about changing Palette and metrics; most of them are out properties! I can't change the Palette except for Palette.color-scheme. That's enough reason for me to not use default slint widgets, instead I'm building my own widgets

[neneodonkor]

Okay. I understand the reasoning behind it. But will it be easy heavily customize the look and feel of the widgets? Please excuse my noob question. I only came across Slint a few weeks ago in my research.

[megabyte6]

It's upsetting that we're going to lose these other options. That was something that pleasantly surprised me when I first started using Slint! However, I understand where the team is coming from, and I agree that this is a good choice (at least for now). I'm glad that the team isn't closed off to the idea of bringing it back in the future if there is enough interest. I'm personally okay with fluent being the default style, but I think that cosmic or qt could've been some good options as well. I'm wondering why the team chose fluent? Surely it couldn't just be because it feels at home on Windows. Qt, in my opinion, also feels good on Windows. It was also fantastic to see a newer player like cosmic being offered as an option for Slint. I hope the team adds support for custom themes so the community at least has the option to keep developing the others while the team focuses on the toolkit. Overall, while I'm shocked about the announcement, this makes sense, and I agree that if Slint is to succeed, it needs faster development and iteration to catch up with other, more established frameworks.

[bjorn]

I'm personally okay with fluent being the default style, but I think that cosmic or qt could've been some good options as well.

Well, I think Cosmic is not generic enough as a default style, and Qt can't be the default because it introduces a dependency on Qt.

[megabyte6]

@bjorn I get your take on Cosmic not being generic enough. To be honest, I just really like seeing something like Cosmic being used outside of Pop_OS! 😅. I personally don't see much of a difference between the generics of Cosmic and other web apps. Many UI toolkits don't "follow the rules". I think that it's okay in this case.

You're right, Qt does include a dependency on Qt. Does this complicate things for commercial apps? Qt's license requires a royalty for commercial apps right?

So, that makes the only two viable options Fluent and Cupertino. I like Fluent a lot more than Cupertino.

Like I said before, I'm saddened by the news and I hope that they let the community keep these these (mostly) up to date, but I understand where they're coming from and I'm supportive of it!

[ogoffart]

I hope that they let the community keep these these (mostly) up to date,

Yes of course, we always accepts this kind of pull requests