What things are you referring to exactly?
1 Like
I’ll post my (increasingly less) minimal ‘hello world’ test project once I’m through with adding test cases to it for all the things I need to have working for the job I’m really trying to do (porting another existing application to work with current Qt/Kirigami) - I’m still sort of hoping there might be a few things we can fix in it because I just don’t know the right incantation yet, but otherwise it should be a reasonable live test for current real bugs and some of what does and doesn’t work.
It’s been mostly crickets trying to get feedback on some of those issues on the matrix channel so far.
But you could get a pretty good taste of what I mean if you try to implement this example: Form layouts | Developer using any version of kirigami more recent than 5.102 from early 2023.
It would probably be a pretty good exercise for whoever maintains that documentation to actually try and use it all on some current system, then get it all reviewed by the current component maintainers - and to have it all assembled as a ‘test suite’ application built for all platforms support is being claimed for. That would go a long way toward making the extent of the current problem a more objective and transparent measure.
2 Likes
I see, removal of checkables in Kirigami that I missed and lack of lineCount (probably a custom function I failed to copy to the example back then…).
I understand you’re frustrated, but the actionable thing to do is to report those issues in the repo. Just the Kirigami tutorial alone is 32 long pages (some due to an update, like the models pages) and I can miss things in them occasionally even when I thoroughly test my MRs.
1 Like
Oh, you maintain that? Ok that’s handy to know. That’s not the only example, it was just a clear and easy to confirm on any platform one. And really it started right from the very beginning of the examples there.
The cmake boilerplate needed for this is a kind of complicated mess of everyone re-implementing what someone else has done, but slightly differently and variously incompatibly. What’s shown there didn’t work for me - though part of that is partly down to the requirements of the full application stack I ultimately need, and the mess that occurs when mixing “the google way” with “the qt way” with “the ecm way” of building for android. That one’s a separate discussion to open and problem to work on once I get my example code posted and reviewed.
Then the very first minimal example didn’t work as advertised either. Even the very basic code shown in Explaining pages | Developer didn’t work as shown in the screenshots.
title didn’t display at all on Android, and Kirigami.ApplicationHeaderStyle.Auto did not work at all - the only thing that did is what the few android-supporting applications seemed to be doing which was always using Kirigami.ApplicationHeaderStyle.ToolBar and setting the page header with a titleDelegate … but they in turn also weren’t using what seemed to be the documented current best practice (in the source code) for many things either.
But it seems the header problem may now be (at least partly, I’ve only initially tested if it really was as we speak) fixed in the last few days with a fix for the Breadcrumb header style – though this has been exactly my quandary - for every problem figuring out whether it’s My Mistake, a change to How It’s Supposed To Be Done, or A Real Bug - and by the time I get halfway to being halfway certain about which of those categories I’m looking for a solution in, I’ve run into 6 other problems, all with the same uncertainty attached.
It’s been an extra-ordinarily slow process of digging through source code and trying to guess intent from sometimes very terse commit messages. It’s been a little reassuring to see that at least someone seems be front running me by a couple of days and fixing some of them in something close to real time as I’m stumbling over them - but these aren’t the sort of problems I would have initially expected to make it into release versions, so that’s been a learning experience all of its own.
And then there are things like:
https://bugreports.qt.io/browse/QTBUG-124926
and
qrc:/qt/qml/org/kde/kirigami/private/globaltoolbar/NavigationButtons.qml:89:13: QML ToolTip: Binding loop detected for property "contentWidth"
qrc:/qt/qml/org/kde/kirigami/private/PrivateActionToolButton.qml:101:5: QML ToolTip: Binding loop detected for property "contentWidth"
Which clearly aren’t caused by my code - but still need investigating before I can know what if any part they are playing in the problems that seem like they shouldn’t be happening.
I understand you’re frustrated
That people are (and some of the concrete reasons why they are) - is mostly just linking this back to the original “What are your reasons for not adopting Kirigami” question that this thread forked from - just ranting about being frustrated is not why I’m posting all this.
It’s the concrete problems and if and how they might be fixed that I’m most interested in.
the actionable thing to do is to report those issues in the repo
I’m very comfortable with code, it’s not a new thing to me - but I am still wrapping my head around both QML’s quirks, and the somewhat byzantine structure of KDE and who is responsible for what, where they like to triage and discuss things, and how responsive they are likely to be.
So I’m happy to report (and even send patches for) bugs - but right now probably what would be most helpful is knowing the right place to bounce the initial problems off to get some guidance on whether it’s Already Known, Something I’m doing wrong or should investigate more, definitely a bug that should be reported, or Only Going To Get Fixed If I Send A Patch.
It’s not like I think I’ve found A Bug. It’s more like I’ve lifted the mozzie net and they are everywhere I look - so it’s a problem that needs a more nuanced plan to solve than ‘hit it with a rolled up newspaper’. Swamping y’all with untriaged reports just creates its own People Are Already Too Busy To Solve problem.
I was sort of hoping the matrix room might be good for that, but so far not so much - so mostly I’ve just been collecting them as examples and notes in my testbed code to share once I’ve done my best to make what’s in it work as well as is currently possible. Then if nobody else responds, I can move on to the other things I need to get done with a clear conscience and without it hanging as a half-finished job over my head too …
2 Likes
Could this be made into a KDE goal? I mean documenting this and planning to focus on fixing Kirigami and all the application that are not using QT at the best of its possibilities?
Maybe not, because without enough people to fix speed up the bug fixing of Kirigami, and to produce new documentation and guidelines, talking with the maintainers of all the application would be useless.
1 Like
Considering how easily customizable KDE is, visual consistency is one of the first things that should be ensured in Kirigami apps.
Even though Breeze is KDE’s current QT style, it shouldn’t be used as the default for Kirigami apps. I suppose the right choice would be Fusion or Windows, which already come with QT apps even when Breeze is unavailable.
1 Like
@Kyuyrii, although Fusion isn’t brilliantly-designed, it would stress-test Kirigami.
I don’t see how those two statements segue - they seem directly contradictory. Kirigami is part of KF, and is the QML interface to it - so a KDE app looking like a KDE app “by default” seems sensible enough.
As does an application developer wanting their app to look ‘platform native’ when doing that makes more sense than looking like an integrated part of KDE.
I suppose the right choice would be Fusion or Windows
Why would I want my KDE Android app or Plasmoid to look like Windows?
But either way, the problem case here isn’t “what is the default” - and the default on Android isn’t actually Breeze - you need to jump through a whole pile of extra hoops to get a ‘minimal’ app to use Breeze there.
The problem case is that if you don’t jump through those hoops, or want to use a different style (like the Android default ‘Material’ - which also isn’t actually a ‘platform’ congruent style despite the name) then lots of things simply don’t work at all.
And that this comes as a rude surprise to developers after reading promises like:
The Material style is a 100% cross-platform Qt Quick Controls style implementation that follows the Google Material Design Guidelines. The style runs on any platform, and looks more or less identical everywhere.
Which to be completely fair, is a promise made by Qt(Quick), not Kirigami - but I’m not sure that splitting that hair does the “this is a mature and reliable technology you should totally use for your next major project” argument any favours just the same.
We’re a long way from having the luxury of bikeshedding over what the default should be in any meaningful way. Right now, I’d be delighted to just have any theme actually be “100% cross-platform” in a genuinely functional way - because even Breeze isn’t up to that mark yet. It’s just the Least Bad choice at present if you’re optimising for ‘least amount of incomplete functionality’.
1 Like
The QT style I see used by default in QT apps is Fusion. Kirigami apps are also QT, but they don’t follow this standard.
The QT Breeze style is primarily used in KDE, but some KDE and other DE users use other QT styles: Fusion, Windows, Oxygen, and Kvantum.
A QT app only working properly in one of five styles gives the impression of being incomplete. It’s as if I’m using something that’s still in alpha/beta.
KDE is considered customization-friendly, but when trying to customize KDE, QT apps become inconsistent because of Kirigami (and there’s also the issue of the lack of Kvantum support in Snap apps).
It’s not something you can ignore; it’s something the user sees all the time: the interface.
In other words, if the user doesn’t want design inconsistencies, they’re basically forced to use the QT Breeze style.
1 Like
@Ron, Fusion appears to be statically linked to Qt in Fedora:
It’s why, when using Qt 6 applications on Plasma 5, one sees Fusion.
can you clarify what you mean when you say that
Kirigami.Themestuff doesn’t work with non-KDE QQC styles
The issue is that for a style to integrate nicely with Kirigami it needs to implement a platform theme and if it doesn’t then Kirigami will use a default basic theme that uses hardcoded values for colours, units, etc. The problem is that components within Kirigami use Kirigami.Theme, so even simple controls can look off. For example Kirigami.Headinguses the wrong font size on Material, and Kirigami.SubtitleDelegate incorrectly inverts the text colour.
The obvious solution here is to implement a platform theme for each upstream style, but probably no one wants to put time into that. I suppose the default platform theme could also be adjusted to fit the “Basic” Qt quick style instead of whatever is currently implemented (probably a copy of the Breeze colour scheme), and hopefully that would look better for most styles. Or perhaps some of the colours can be copied from the current QPalette.
A QT app only working properly in one of five styles gives the impression of being incomplete. It’s as if I’m using something that’s still in alpha/beta.
The only upstream Qt Quick styles that look decent by default IMO are Material and Universal. Fluent has potential but it a bit rough around the edges. The only platform-specific style I’ve tried is the Windows one which left a lot to be desired.
But the problem with Material and Universal is that they use hardcoded font sizes and don’t seem to provide any method of querying the font size in the app. So if you want your app to integrate properly with Material you’ll have to hardcode those font sizes yourself inside the app. And if you want to support more than just Material, then you have to either (1) stick to using only the default Qt Quick Controls with no custom contentItem, or (2) implement a Kirigami Platform theme for each style you want to support.
Presently it seems like no KDE developer is interested enough to implement these platform themes.
That all seems like a pretty fair and accurate summary of what I’ve found while digging into this deeper and trying to find fixes for the things I need working on Android.
I’d just add one thing to:
In that the problem(s) with doing that seem(s) to be magnified by the nature of “declarative configuration” in general, and QML specifically.
Because there isn’t actually any ‘programming’ involved (except behind the scenes in C++), there isn’t any real code or logic or design rule re-use possible other than simplistic inheritance or mix ins - which means pretty much all QtQuick ‘native’ controls are inherently a mix of some copy and paste duplication of boilerplate they all need, and the extra things they provide that makes them a New Control.
That in turn means that pretty much all “styles” of those Controls involve copy and paste duplication of the entire original Control definition, and then modifying it to fit the motifs of the new style. There mostly isn’t any real interface for “styling”, there’s just duplicate, reimplement, replace.
Which means any change upstream in something fundamental (like the requirement to support SafeAreas, or how size and layout is propagated - just to name two that happened nearly a year ago which the existing Kirigami platform themes are yet to be updated for), requires re-copying and pasting all of those changes to all of those controls, everywhere they have been used. Not just making that change in one place upstream and then having everything use it immediately and automatically.
That’s a problem the QML design created, it’s not something we can fix in Kirigami - but it is magnified in Kirigami by both the requirement to support a range of older Qt versions and by the fundamentals behind:
Presently it seems like no KDE developer is interested enough to implement these platform themes.
Which of course is a complex time/process/manpower/volunteer-interest bottleneck-shaped thing, not just simple lack of desire.
But that doesn’t make the problem less real, or take it out of Kirigami’s ballpark to find a workable solution for. I have every sympathy for “I don’t have all the time I’d like to spend working on this”, none of us ever do - but when something is bitrotting faster than you can repair it, at some point you need to think about either making it easier to repair, or simply taking it out of the loop entirely so you can devote more time to the things you are interested in and have time for.
Just leaving them in the path for people to bark their shins on will only make people look for another path.
@jackh I see you have a bunch of QA fixes for breeze-style that have just been getting rebased without comment or merging since … March? What’s the broader story with that?
I was considering contributing the gruntwork needed to pull in the Qt changes once I get everything that’s more pressing for my immediate need fixed - but if there’s no manpower or interest in properly reviewing and merging contributions of manpower, then that seems like a separate chicken and egg problem that someone is going to have to be brave or bold enough to crack?
the actionable thing to do is to report those issues
only really works when the circle is completed by reports being acted on.
Seeing the problems and fixing the problems are the two inseparably essential parts of improving anything, and improvement always happens fastest in the spaces where that is a cooperative and communicative process, not an adversarial one where silence is only broken to downplay or dismiss reported problems.
That should be easy here, because ultimately we all want the same thing - there’s no dilemma of incompatible choices - just … what? inertia?? Or something else?
How do we actually fix this?
Discuss.
2 Likes
This is partly my fault for not actively seeking a reviewer. I’ve pinged the development matrix chat so hopefully someone will see it soon.
2 Likes