Separately from even this current thing I’m working on, QML hasn’t really been doing a very good job of selling itself to me.
It’s probably nice if you’re the author of a GUI “app creator” - because the severe limitations of what you can do with a drag and drop designer map pretty directly to what you can and can’t do in QML, so it makes your job easy and its fine to have unnamed ‘Rectangles’ and ‘Items’ scattered and nested all over the place. But if you’re actually a programmer - then taking away your ability to program solutions to some problem isn’t really A Feature. It’s the Framework Problem with the dial set to 11. You start with all the same problems that QtWidgets handed you, but with even less ability to do something to mitigate them.
So if you’re working with Android, and already paying the price for using ‘native’ code there, adding yet another layer of interpreters to the several layers you already need to deal with just to get one line of text on the screen, might not be the ideal first choice for more reasons than just this problem.
But in my case, it’s not my choice to make, I’m starting from existing code - so I either port all of its QML back to QtWidgets (which long term I’m not taking off the table yet), or try to make its current code work with Qt6.9 and Android 16 with the minimal number of changes. And that seemingly simple job got so bogged down in repeatedly crashing hard into dead ends of mutual incompatibility with current tooling, that I figured I should take my minimal hello-world that I tested the Android build environment with and turn it into a minimal Kirigami example I could use for testing and reference to update this other app.
And that’s where the nightmare really began. The internet is full of examples of doing that, with varying degrees of being ‘official’. Half of them are still for Qt5 and haven’t been updated in 6 - 9 years. None of them work out of the box with current HEAD of all the things they use, and all of them are in varying states of using things that have since been superseded or for which there are multiple competing implementations.
There’s the google way of doing things - because they ship their own cmake tooling that their SDK tools assume you’re using - actually they ship two to choose from, because both of them break in different ways with different use cases. And there’s the ECM way of doing things, which some of the KDE deps assume you must be using, and some of which will almost but not quite fall back to the Qt implementation when you have a New Enough Qt.. And there’s the Qt way of doing things, which reimplemented much of what ECM pioneered, but changed all the configuration and output variable names again, along with some of the behaviour … And then there’s dozens of end-user permutations where “some from column A, some from column B” is what people were able to make work over the years, all of which probably stopped working just a few releases after they were created or only work under strictly controlled pre-conditions.
And those independent implementors don’t appear to be talking to each other or to their users, and even themselves seem to know they’ve created such a horrible convoluted mess that they can’t and don’t give you a minimal working raw code example - they just fall back to “use our designer GUI, it’s all hidden behind that”, and use our special build tooling, where we hid the rest of Too Hard To Explain. And so now you faceplant into another mutually incompatible choice - especially if you’re starting from existing code that wasn’t built with or designed to use any of those things, and may itself have it’s own string and duct tape build tooling, which is the reason this hasn’t been updated since early Qt5 in the first place because everyone is too terrified that Touching Anything with Break Everything.
And that fear, I’m living proof to report, is not unfounded.
But after very painfully, and piece by piece repeatedly, discovering exactly why none of what people had documented as “current best practice” actually still was, or even still worked - I think I’ve finally got close to the currently un(der)documented what actually is and does with the current release versions.
And that’s when this little rude surprise sprung itself on me - right when I was thinking “cool, the Hard Part is done, I have a baseline now, I’ll just take a couple of minutes to make it respect the system dark or light theme, then wrap this up and get back to the original job”.
And yeah, I’m totally skipping over the part of this train wreck that is “splash screens” - because again, I’m not writing this to angrily vent my spleen before I rage quit. I’m sharing a real user story to hopefully give a little bit of productive perspective on what actually still remains to be done to make this a practically useful tool for developers. And spoiler alert - it’s not “add yet another language binding to make it easy for newcomers who only speak one language”. Until the fundamental promises being made are things that actually work for people who aren’t scared away by that, that’s not the show-stopper problem here.
Consequently, have you any examples?
I was planning to push this example code to public git, partly to try and save/warn others from/of the pain I’ve just been through - and partly as a ‘living bug report’, that will hopefully get the official documentation improved, or stand in for it until it is, and maybe shake out a few pointers to things that could still be done better or cleaner than I’ve already done them.
Once I’ve got this bit of the mess that it became while trying to find a way to make this work cleaned up as best it can be again I’ll look at doing that.
I have been able to utilise the
MaterialandFluentWinUI3styles in pure QML, but haven’t evaluated whether they’re compatible with Kirigami myself.
See the side thread that runs from here: Styling Kirigami applications wtih custom QtQuickControls Style - #25 by Ron when I thought that error was evidence of a problem in what I had done that I needed to fix - before tracing through enough of the code to realise that it was a “situation normal, this is never going to work until kirigami is fixed” warning that kirigami didn’t actually support the QQC styles - the only way to use them is to ignore Kirigami.Theme and hardcode use of the QQC style directly in your code. Realising that and searching for any known answers was how I found this thread.
And it’s even worse because if you specify no styling (and don’t bundle breeze) then Kirigami will default to Material on Android, but not to Material.System which respects the user’s device setttings.
I’d be ecstatic to be horribly wrong about this, and see someone say “dude, what are you banging on about, you just need to do X, and all of this really does Just Work” - because that’s what I believed a couple of days ago… but at this stage that hope is fading pretty quickly with every new piece of evidence I unearth.
It’s not even a “worst fears coming true” thing - this seems like functionality so basic and fundamental that it’s more like finding out the Easter Bunny isn’t real and the factory that makes chocolate eggs is broken and can only make the foil wrappers for them. It’s not at all what the more naive and trusting me from a few weeks ago was led to expect.