We need your thoughts on Kirigami

I think it’s also worth noting that we seem to constantly get half way through this discussion and then fail to make a choice.

So the question this time is are we actually going to make a choice or will this just be left hanging again.


@sanjay-swain There was that blog post : Linux applications with Python and QML – dimitris.cc – Notes on technology and freedom

What about theming? Probably not the most important thing to work on but still
worth mentioning.

I know this is probably a weird and impractical thing to ask, but KDE Plasma
allows you to change the Qt styling such as Kvantum and Oxygen, however, on Kirigami apps, it only changes input widgets in the page changes (such as buttons and line inputs). Actions, cards, and the overall appearance of the applications remains unaffected except for color schemes. Would it be possible to be able to allow the user to change the theming of Kirigami applications such that it can resemble other styles besides Breeze?

There’s also theming on other non-KDE desktops, where if a can recall
correctly, Kirigami applications just strait up have broken themes there, even when using qt5ct/qt6ct.

Kirigami inherits the basic feeling of Qt Quick itself, which compared to QWidgets feels like a random toolbox of items that are sort of made for desktop apps, but actually not really because you run into all sorts of small inconveniences along the way.

Things like having several different versions of global sidebars, but no help with organizing all of the app’s actions into a comprehensive menubar. Arbitrarily placed hamburger menu buttons that have nothing in common with the automatic hamburger menu button from QWidgets. Components that assume you’ll put them in a form layout or they won’t work correctly.

Page stacks that awkwardly leave a page open by default after navigating back, which also makes OK/Cancel weird in page stacks. Global context sidebars that don’t have built-in PageStack functionality, inflexible page pinning at the left or even right of the view, pages can only be added on the right but not in the middle. Huge wasted space for page titles when the window title just above shows the same thing already.

Form layouts that can’t align the form label with the topmost element of a two-row control, and when you finally find top alignment, it doesn’t align with the top control either. So instead you’re just going to split your two-row control into two separate items, which doesn’t help with reusing it elsewhere.

It’s the thousand papercuts, when I think hey, this looks like it should solve my problem, but actually no it doesn’t.

Qt Quick feels like it’s made for companies that have a very good idea of what their target device is, and that want to provide a custom (probably embedded) company-branded UI to users. Desktop and common look&feel across apps was and is an afterthought for Qt Quick. Basic controls such as lists and comboboxes require me to copy and paste code to calculate text metrics so that at least my initial set of text items doesn’t get cut off.

I’m looking to Kirigami to help me with making a standard app that looks & feels “right” across desktops, where the easy way to use it is also the one that works well out of the box. But the navigation components make for a poor default experience, abstractions are leaky, and in the end I need to hardcode lots of stuff that I know will break for a user with non-standard setup.

Kirigami is not the best at mobile, it’s not the best at “custom branded” cross-platform, and it’s not particularly great at guiding users towards making a decent “standard” open source desktop app. It gets you some improvements over the poor state of Qt Quick, and that’s a good reason to include it if you’ve already decided to use that because QWidgets is on life support. KDE obviously nudges apps towards Kirigami so that’s a handful of developers that will use it no matter what. But no hero use case(s) to get excited about.

Assuming the Kirigami team knows who their target “customer” is, I think it would help to tightly collaborate with one particular project/team and knock it out of the park for them. Then another one. Do you want to provide all the components for an existing QWidgets app to port it to QML without regressions? Do you want to support a new app in making their non-standard UI paradigm work? It’s okay to be mediocre at many things as long as you win hard at some of them.

Furthermore, it would be nice if the vision and target “customer” of Kirigami is widely communicated to the public. This thread’s opener is unfortunately similarly vague: Adopting Kirigami for what kind of app? Top choice for solving which problems? I know it’s meant to be open-ended, but imho more focus on a subset of framework users could help with moving towards Kirigami kicking ass. It also makes for good blogging material.


Yeah but none of those are supported “officially”. It is really hard for newcomers to learn everything on their own when their is no actual documentation or support.

I think we should also support Python as Kirigami programming language and give it some love. Not every app needs to have “faster” C++ language. Many day to day application are never going to use 99.99% of features from C++ language. Python will be great for beginners to get into development.

I think Kirigami developers should give first class support for developing with Python. At the very least the documentation should say it is possible to develop Kirigami Application with Python and provide relevant links to other sources. As far as I know the documentation don’t even mention Python currently.

1 Like

Also for Kirigami to be on the “top” it also needs to have proper documentation for Cross platform. As seen on another recent thread:

Cross platform support is something missing from GTK apps QML/QT is already in a much better position in that regard as QML can “work” on Windows. This is important because not everyone creating apps wants to make apps just for KDE. If Kirigami wants to be used as an alternative for developers who have no idea about KDE ecosystem it needs to have all these support to make their life easier.

1 Like

I feel like this is something we need more contributors for, there’s only a handful of people working on Kirigami. Even less are interested in documentation - which is completely fair! An even smaller portion of that group has the time, energy and drive to test it on Windows unfortunately :frowning:

I personally would love a better Kirigami story on Windows (and macOS), but it’s unfortunate I don’t have much interest of supporting Windows (due to various roadblocks upstream and downstream), the time required and the fact that I don’t even use Windows often. I’m guessing lots of other developers share some of these problems…

1 Like

Definitely agree to that. Deploying my recent Kirigami project to Windows was (and still is) a rather big task that is annoying and painful through and through – and only few parts of that actually have anything to do with Kirigami, its dependencies or documentation. Developing on Windows just sucks and I hate it with every fiber of my being – regardless of framework, technology stack or language.
Mind you, I’m obviously not a Kirigami developer, but even if I was I’d only very reluctantly want to work on Windows compatibility and testing.

This does feel like a bit of a chicken and egg; few developers with little motivation to support Windows, means less potential users (both dev-users and end-users) means less potential new contributors, means few developers with little motivation to support Windows, means…

1 Like

I have to say Kirigami looks pretty good now, with the redesign lately!

The only thing, after the switches, scrollbar, rounded corners etc are fixed, is the small b/w sharp icons…

They are the same as in the Plasma systemtray I think? I like the Adapta icons way more, or also most GTK icons. That is the last step to make these apps look great


The icons make other apps look pretty bad too, like GNOME or Mate apps on KDE. I dont know, they seem like pre-Win10 and stuck in that area, while Win11 solved that design mess. Androids material icons for example look way better.

but true, the dropdown dialog is completely sharp-edged and the selector is too. It also looks very much simpler than on QtWidgets?

Small question, do you know of graphical bugs in Plasma6, like the dropdown being too small to fit in all elements, or popup windows sometimes spanning to the bottom of the screen?

Last thing about style is fonts. I use Inter medium for Plasma, Firefox and Thunderbird now (including all websites) and it looks great! I heard from MiiBeta that Plasma has bad thin font rendering? That would be fixed too. Google Noto is simply very basic, I dont know it somehow looks bland. Dont know if the font is some preset in Kirigami though, but it improves the “modern app appeareance”

Btw. do you know Slint? It inherits the Qt look completely, but is completely written in and for Rust. On Windows and macOS it uses their native styles, it works everywhere, there even is an UEFI demo! I think that is pretty exciting

QtWidgets’ appearance is very mature, and does everything it needs to do very well. Kirigami still looks a bit raw on some edges, and does not look as polished. It offers a new style, at the cost of maintaining two different styles, trying to make them look similar, and doing constant plumbing.

Maybe a single interface style for desktop and mobile does not work so well after all. Taking cues from SwiftUI, having separate UI code bases for different paradigms allows tailored experiences, optimised for the said device. Of course the desktop styling should be identical to QtWidgets, maybe wrapping it in QML (don’t have any idea if it’s possible or not).

That’s what we do right now, using qqc2-desktop-style to apply theming from the QStyle to QML-using apps. However this is one of the source of the “doing constant plumbing” issues you mention. Nothing’s ever free. :slight_smile:


When this post was recent, I mentioned that Kirigami apps can be broken on other DEs. This is like what’s the worst of what could happen if you have qt5ct turned on.

I think that happens when you are missing a package.
Check if you have qqc2-desktop-style installed

Yeah, it’s installed.

It’s probably not being used by default, on KDE Plasma it’s enforced by plasma-integration or by the applications themselves. You can force it manually via QT_QUICK_CONTROLS_STYLE=org.kde.desktop

Let’s stay on topic :wink:

There’s also more I want to add. Compared to GTK apps, resizing apps feels finicky. Notice how below that components get displaced before being corrected.


I don’t know if it’s the app itself that’s the issue, but I’ve seen it a lot in Kirigami apps.

1 Like

It’s one of the things that annoy me the most about it, but AFAIK it’s a general QML issue, not a Kirigami issue.

1 Like

Yeah, I still remember doing generic QML tutorials and this being an issue. Is there anything the Qt Company or KDE doing or can do anything about it?

I have had experience with the same problem.
It is less like “fixing itself” and more like:
For certain window sizes, the placement of elements is totally off and fixes by just changing the size by a few pixels. (the exact window size when it creates problems, depends upon your application’s elements and their placement, so it’s different for all)
I thought this problem was because I was using an older version of Qt (5.14.2) when QML was relatively new and hoped that it would fix itself in later versions, but if Qt 6 is having the same problem, perhaps we need to bump this.