Kirigami doesn't adhere to platform styles. It should

[rokejulianlockhart]

Was going to add this as a response to the undermentioned. However, this topic is not entirely development-oriented:

We need your thoughts on Kirigami

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.

---

One reason that, as a user, I don’t use Kirigami-based applications on my AOSP device is because their GUI is no utterly different to all else.

One of the reasons that I like Qt is that, by default, its platform style differs per platform, attempting to mimic standard controls for the platform. KDE Frameworks tends to override this, although it never applied to AOSP much anyway. Irrespective, Kirigami makes no effort to remediate this.

To compare, I utilize most modern AOSP applications, whether they were created in Flutter or Compose (etcetera) isn’t even noticeable, because they all mimic Material 3 (+You), whereas Kirigami does not even attempt to adhere to my accent colour.

Not adhering to the platform style is a jarring departure from what’s standard, and not for the better.

…It’s even more so when these controls are arcane:

This is relevant because in this case, I’m rather surprised that it doesn’t adhere to the system font by default, if it’s going to be nigh unusable.

[johnandmegh]

Yeah, I suspect what you’re seeing is ultimately the user-facing impact of the developer issue that was mentioned here:

@carl

a lot of questionable default which needs to be overwritten in every apps particularly for better mobile support

Plus the fact that it sounds like more of a “collection of useful components” than “a vision for applications, with components to help implement it”.

So if the default doesn’t innately work well for mobile, and there isn’t necessarily a unifying, prescriptive view on what principles folks should design toward, it does make sense that things would end up “functional, but feeling clunky”.

[ngraham]

Kirigami itself can use whatever QtQuick Controls (QQC) style you want, and Qt comes with a Material QQC style. However many KDE apps internally specify what QQC style they want rather than inheriting from the system’s preferred style. Why? A couple of reasons:

1. The concept of “the system’s preferred style” is only a thing outside of the Linux world; there’s no “GNOME QQC style” or “XFCE QQC style” that such systems will specify for the app to use, because neither the people involved with Qt nor those environments have created such a relevant QQC style for apps to use. As such, this concept only really makes sense when you’re running the KDE app on Windows, MacOS, or Android, where Qt itself provides some QQC styles that attempt to mimic those platforms’ styling.
2. Even when such a QQC style is available for our apps to use (e.g. on Android), KDE apps often aren’t tested extensively or at with them. As such, many of the developers decide to play it safe and require the use of the Breeze style. Should we make an effort to move away from this? Probably. But it’s mostly a matter of time and resources; testing your app on a bunch of different platforms isn’t fun or rewarding, and often not possible at all if you don’t have any of those platforms around.

Hopefully that helps to clarify the situation.

[rokejulianlockhart]

@ngraham, yeah, it does. However, for something like Flutter, there appears to be a whole raft of well-designed platform-specific adaptations: ^[1]

- OS: AOSP 14
  Design: Material 3 + You
  URI: https://m3.material.io/develop/flutter

- OS: macOS
  URI: https://pub.dev/packages/macos_ui

- OS: Windows 11
  Design: Fluent Design
  URI: https://pub.dev/packages/fluent_ui

Is there something about Qt6 (or KDE Frameworks) that makes it more difficult for such to exist?

---

1. Automatic platform adaptations | Flutter ↩︎

[ngraham]

Qt already does include styles for Android, MacOS, and Windows. I don’t know how good they are because I don’t use them, which I suppose is the issue in question: People need to have the desire to use non-Plasma platforms and want their KDE apps to look native-ish on those platforms before the motivation to make the situation better there will ever materialize.

[rokejulianlockhart]

For comparison, it unfortunately appears that GTK’s AOSP backend doesn’t introduce platform-specific stylisation. (…Yet? It’s in an alpha state.) Though, considering GNOME’s developing it, that might well be deliberate!