Question for all:
What are your reasons for not adopting Kirigami in your development? What does Kirigami need to be a top choice?
Please list out your requirements in the comments.
My tiny problem with Kirigami is that there are minor differences between widget and kirigami styling… Mostly when it comes to frames and separators, or roundness of frame rectangles, or combobox dropdown menus. If these minor differences can be solved and Kirigami can follow the QtWidget style more closely, that would be pretty nice.
Some could say these are tiny nitpick issues and I would agree… But it does sometimes look a bit off when two apps have different looks for same elements.
For example:
Qt Widget
Kirigami
Other than that I do not really have anything else to contribute to discussion.
Edit: I learn that it’s not necessarily kirigami style, but the qqc2-desktop-style. Or both. Anyway, something to think about.
5 Likes
As someone who recently turned one of their pure (non-KDE related) QtWidgets applications to Kirigami, I feel like this is a perfect topic for me 
I didn’t adopt it earlier because of the dependencies, and I find the more dependencies I add the more pain I experience. I do know people who get this working somehow, by using Craft to build Windows/macOS binaries since that has recipes for KDE stuff obviously. Now that I’m targetting only Linux, it makes choosing Kirigami a more obvious choice 
As for using Kirigami, I find it pleasant to use especially once you start piling on stuff like Add-ons. I can’t really think of anything concrete off the top of my head, apart from the usual QtQuick issues (like context menus.)
I still feel like I don’t know half of what Kirigami (and the surrounding KDE QtQuick-related frameworks) can do, and I contribute to them 
I feel like we really need more powerful and great Kirigami applications to really sell the framework, that’s the kind of mindset I have with Tokodon. There’s plenty of other applications too, like NeoChat and Kalendar. I don’t pop open the Kirigami gallery regularly, but I do use Kirigami applications all the time and there’s where I learn the most from.
5 Likes
I’m probably the one who maintains/contributes to the most Kirigami apps and these are my biggest issues with Kirigami (warning rant ahead)
-
a lot of questionable default which needs to be overwritten in every apps particularly for better mobile support. To give some examples: the global drawer doesn’t automatically change between modal and collapsed and this requires a lot of custom codes. The toolbar also always requires some custom configuration and here is that I have to put on every of my apps src/content/ui/Main.qml · master · Network / Tokodon · GitLab
-
a lot of APIs are quite inflexible due to the amount of magic. Global drawer for example only allows to provides Kirigami.Action, which means that it is impossible to add custom content to an entry (e.g. unread count). I generally avoid hlobal drawer completely in my apps unless it’s using
isMenu: truewhich tranform the drawer in a hamburger menu. -
a lot of design decision seems very stuck in the past. Kirigami tries to mimick QtWidgets style but that also didn’t change much in 10 years. For example, the typography is very basic. Even Bootstrap which tries to be very neutral in term of design provides both heading and display headings. Typography · Bootstrap v5.3 and it’s not only the typography. It’s aspacing, colors, animation, and layouting. I’m really jealous of the gorgeous look of some GNOME apps https://cdn.masto.host/floss/cache/media_attachments/files/111/246/362/971/454/938/original/4a2f660815d08e5b.png . I know some people don’t want to chase the latest trend and we shouldn’t. But at the same time we should recognize that design is evolving and it’s not something that is done but that instead that there is constantly new research in this area with a lot of positive changes.
-
the documentation is not great and the tutorial is in a dear need of an update and mention all the new kirigami addons utils. This is mainly my fault and I need to find time to do it.
-
Most of the main Kirigami developers don’t actually maintains apps but focus on Plasma. Which mainly means that they are less in direct contact with the app users and don’t necessarily understand the pain of some apps. A good example for that, was the amount of time and energy it took to remove the automatic floating buttons on Plasma Mobile which was the number one complain by the app developers and users on every thread about Plasma Mobile on social media. And it still took years to remove them.
6 Likes
I would like to echo this statement since the global drawer actions list doesn’t play well with dynamic/generated content. For example in Elisa we have this ugly hack to convert our backend content into a list of actions.
Also, since Kirigami has such an emphasis on actions, I think perhaps we should split out the core of KXMLGui, KConfigWidgets, and Kirigami into a more generic KActions library. Then KXMLGui would provide an actions interface for Widgets, KConfigWidgets would provide the shortcuts dialog, and Kirigami does the same for QtQuick apps.
I have noticed that Merkuro, Haruna, and Elisa all make (or made) use of KXMLGui for managing actions, but each app seems to implement the QML interface (as in API, not UI) differently. Haruna even ditched KXMLGui for its own implementation & shortcuts UI.
1 Like
My reading of the situation is that Kirigami’s big problem is a lack of strong design vision and direction.
But in the past Kirigami had those! It began life with a bold and opinionated design that Discover and Peruse faithfully adopted. Unfortunately the design was not accepted by either users or developers. It was too different, too unusual, too awkward, too mobile-focused, too un-KDE-like. It failed.
But the project didn’t get canceled! Instead Kirigami sort of drifted in the direction of being a repo of useful and less-opinionated QML GUI components, because we needed that and it was convenient to use Kirigami for it. QML apps started to use these less-opinionated and more flexible components. Peruse and Discover especially got redesigned to look more like regular KDE apps that just had a modern design.
As a result, I feel that Kirigami today is much more useful and widely adopted than it was in the past. But it still hasn’t articulated an official new design vision, nor does it have the leadership needed to articulate and develop that vision. So we get conflicts over some of the more opinionated proposed components, and over changing some of the oldest parts of its original design, and over what should live where, and so on.
I’d really like it if we all sat down and agreed on a new design vision for Kirigami, one that accepts and embraces what it’s become and how it’s used today, and makes it better at doing those things. And we need to actually agree on it, rather than just discussing in circles.
And I really think Kirigami needs to have a maintainer/leader who champions whatever that design vision ends up as. Even better if most or hopefully even all of the current developers of Kirigami-using software can get on board with that vision and that leader, and respect and accept their decisions even if they don’t agree with them.
7 Likes
As a fairly new developer with Kirigami (a few months on and off working with it) the biggest issue I had was documentation feeling a bit outdated and weirdly scoped - I never quite knew if I should be searching for QML documentation or if that is a Kirigami specific thing. This was especially true when the docs in the “Kirigami Getting Started” page didn’t work because they sometimes were seemingly referring to an older version of it. Admittedly, this is partly my fault because I should have at least written down to report these issues which I haven’t done way too often. In a community run “in our free time” project docs are always hard (I have already made a merge request for docs fixes, but not often enough).
(Edit: to a degree "not knowing if it’s kirigami or QML will always be a bit of an issue when something builds on top of something else, but I feel it could be better. or I’m just dumb, also possible)
Another sometimes small, sometimes big issue around docs is the name itself - I don’t have anything in particular for or again “Kirigami”, but search engines really like to think I’m searching for Origami instructions forcing me to make awkward queries like “Kirigami KDE” or “Kirigami Framework” or similar - this would probably be fixed with more people using it and engines learning the context of what kind of other stuff goes with “Kirigami the programming thing” and “Kirigami the sub-version of Origami”
As far as actually using it goes, I’ve enjoyed it so far - there’s a few weird things but nothing weird enough for me to remember it. I do want to chime in on the global drawer and floating action buttons mentioned before: I would like for the global drawer to be more flexible, but I also really enjoy the “automagically it just works” way it operates now. And the floating action buttons… well, I always found them kinda ugly but I loved the idea of having a proper way for bottom aligned controls on mobile. I don’t understand why any mobile UI design includes top aligned buttons that are intended to be used a lot in nowadays world of gigantic smartphones - the top should never be regularly interacted with and should only be there to show more content. If I can throw my probably fairly insignificant hat into the ring I’d like to vote for the “radical new design choice/vision” of Kirigami to be bottom aligned interactions on mobile and somehow marry that with an at least somewhat traditional design on desktop
PS: I also really enjoy how easy and seamless it is to get a mobile version for “free” when making a desktop app or vice versa. It’ll not be perfect, but it’s surprisingly quite good even without some manual work for the specific form factor - at least from my experience in my one project so far.
5 Likes
I also hit the same trouble with this I usually use my search engine to land on the API doc page instead of using the built-in search, and I usually have to put in “KDE Kirigami” as well. I’m not familiar with SEO, maybe that’s something that’s fixable without having to rename the library which already has a lot of weight behind it.
1 Like
yes, this.
Anything else is just doctoring on implementation details, which isn’t very productive if we don’t know where we want to go
It would be nice if Kirigami could support apps in the KDE ecosystem to provide a common design language and workflows. Right now, there often are at least two different solutions for the same problem which leads to inconsitencies. Additionally, it’s not clear to me how decisions about the direction Kirigami should head in are taken.
See also Towards Kirigami Add-Ons FormCard - or not?.
1 Like
So far I am reading that top priorities for Kirigami are:
- Vision and Mission
- Visual alignment with other frameworks
- Keep building addons
- Create standard components
4.1 Enhance Global drawer - Redefine defaults
- Make APIs more flexible
- Update GUI styling to meet current UI standards
- Strengthen documentation
Can you all think of any others?
2 Likes
As someone who was quiet involved in documenting the original (design) vision of Kirigami, to me it seems that the most basic question about Kirigami is still unanswered:
Is Kirigami supposed to be used to create apps for KDE Plasma - or is a general purpose framework, to create mobile / convergent apps for different platforms iOS, Android, Windows, KDE Maui, … with qml and Qt ?
(And I’m not talking about technically creating apps that run on those, but apps that look and feel native on the platforms)
If it is a general purpose framework, then it should adapt to the design vision of each platform as much as possible?
But if it is KDE Plasma only, then it’s probably KDE Plasma that’s lacking the design vision?
8 Likes
There is MauiKit that use Kirigami and it seems quite nice visually. Maybe a convergence could be nice ?
I’m pretty sure this is already answered: Kirigami is not intended to create Plasma-specific apps. It has always aspired to be cross-platform and cross-form-factor.
1 Like
One important thing come to my mind. Lack of support for Python.
I have very small experience with C++ and prefer Python much more when it comes to desktop apps (I have most experience with C/C++ on embedded or Arduino platforms). Honestly I know there are QT/QML bindings for python but I still can’t figure out a way to use Kirigami with Python. And the documentation is nonexistent aside from few short blog posts from years back.
The reason GTK is so popular because it have binding and documentation for a LOT of programming languages. I know it is not possible for QT since is is build on top of C++ not C but having official support for Python with Kirigami will go a really long way.
1 Like
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.
2 Likes
@sanjay-swain There was that blog post : Linux applications with Python and QML – dimitris.cc – Notes on technology and freedom
1 Like
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.
1 Like
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.
9 Likes
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.
3 Likes