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.
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
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…
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…
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.
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.
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
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.
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.
I think Kirigami developers should give first class support for developing with Python
Lord, the amount of new development we’d see if a couple of interpreted languages were supported for KDE apps! I know everyone loves to hate on JavaScript, but allowing web-devs a simple point of entry to KDE desktop application development would absolutely open the floodgates. I’m super comfortable in JavaScript, and I’d desperately love to contribute to some KDE projects or work on my own desktop applications, but the barrier to entry (learning a low-level language) is massive; it just seems like I’m going to be spending ages in the trenches learning some new, obtuse syntax before I can make anything. (Plus, it seems like Rust is a better alternative to C++ so I feel like I might be wasting my time learning C++.)
@Nathan, I’m the same. I’ve already created a few Qt6 apps in Python 3.12, and I’m primarily a DotNet developer - C# and PowerShell - so I really don’t want to learn C(++) for anything if I can use Python instead. The fact that C doesn’t have a package management solution like pip (and CMake is probably the most convoluted mess I’ve ever investigated) makes it quite a high barrier to entry.
Even if Rust wouldn’t permit dynamically linked binaries (which is problematic for security and efficiency) it at least provides rudimentary dependency management, so it’d be better for those like me.
@Atem18, I don’t want that. I find MauiKit intensely ugly, not least because it doesn’t adhere to any user-configurable centralized theme. In fact, it’s inconsistent regardless.
Regardless, to my knowledge, their codebases are utterly divergent, so the sole conjoinment possible is a combination of the development teams and abandonment of one project in favour of the other.
@redstrate, I’d be willing to test on Windows and write enough documentation to fill your ears, but I’m just not a C++ or QML developer, so I’d be incapable of it.
I’m stating this because I expect that there are many people who are the same - would like to contribute, but merely lack the skills necessary.
I think what makes GNOME a popular target for developers is the amount of language bindings available. It’s easier to learn and adapt to new things if youre comfortable with the language. Ive tried Python+QML but there are no bindings fo KDE specific things, so even tho theorically u can make Python kirigami applications the support is very basic and many Kirigami components cant be used. Python might not be the fastest or greatest language out there but its very popular, im sure having official support for it would attract some devs. I have one or two apps i’d love porting or creating a kirigami version.
