In the bottom of kickoff settings i.e. right window, buttons are missing.
Plasmashell doesn’t start at all with oxygen now, giving libEGL warning: egl: failed to create dri2 screen. That’s why I used plasmawindowed. This is a clean VM, to make sure the rest of my config isn’t to blame.
Did you install Angelfish as a Flatpak, by any chance ?
This is the kind of error I get when I launch flatpaks. I’m aware of the issue, though not really sure about how to fix it. The custom style is just not visible for the Flatpak, and that’s by design. I believe the application would still launch if it used the setFallbackStyle function to fallback to a QtQuick style that’s guaranteed to be available. The KDE template for Kirigami applications doesn’t do that, so most Kirigami applications are bound to fail to launch when installed as Flatpak with the QT_QUICK_CONTROLS_STYLE variable set to a style that’s not included in KDE’s SDK Flatpak.
As for how to allow for use of a custom style… I’m not too knowledgeable about Flatpak, I found some discussions about it concerning GTK/QML/Qt styling with Flatpak: I’m not sure, but it would seem like you’d need to install the style as a Flatpak too, or something like that.
Sorry to hijack this just a little, but is there some documentation detailing that somewhere?
I’m seeing the same sort of thing trying to add some basic styling to a minimal kirigami app on android (enough to get it to respect dark or light system settings initially):
kf.kirigami.platform: Failed to find a Kirigami platform plugin for style "Material"
And that style only seems to exist as 2 qml files, so I’m still trying to figure out how to bundle it into the APK with kirigami and Qt.
I couldn’t reproduce that issue at home, but I cloned the Kirigami platform plugin from org.kde.desktop. The installation looks okay. I thnk it’s going to work. Can you rebuild from master and tell me if it’s okay now ?
The Spectacle missing preview has been fixed.
@ron There’s no tutorial, as far as I know. There’s documentation for the involved type which can tell us more precisely what we can do with it: I know for sure I had it in a browser tab this afternoon… I just can’t get my hands on it anymore. Anyway, I think what you need is pretty much to implement this for your style: kirigami-plasmadesktop-integration · master · Frameworks / QQC2 Desktop Style · GitLab
Build has been fixed. Your patched kirigami, along with the latest commit, fixes the issues with the libplasma dialogs and spectacle. System settings is broken, however. When I try to open any KCM, system settings closes and opens again. Drkonqi is unable to take a useful bug report in the vm for some reason. System settings is also borked to a lesser extent when I use QT_QUICK_CONTROLS_STYLE=org.kde.breeze.
Do you know any way to set QT_QUICK_CONTROLS_STYLE=org.kde.desktop for plasmashell and system settings, while having QT_QUICK_CONTROLS_STYLE=org.kde.oxygen for everything else?
Thanks for the tips on that - I’ve been tracing through the code and poking at this more today, and it seems that warning is actually just a red herring and an ‘expected’ result from current kirigami (and its ongoing lack of integration with the Qt Quick Styles), not an indication of some remaining problem with the apk that I’d created or with what I was doing.
It’s quite possible I’m still missing something important here - but this all seems to be quite a mess. If I want to have an app that respects the user’s system-wide dark or light theme choice - it seems that I either need to commit to using breeze on all platforms, and use Kirigami.Theme.* in QML - or commit to using Material.theme: Material.System and Material.* for styling instead of Kirigami.Theme, and use the Material style on all platforms.
Since there’s no way to do the equivalent of #ifdef Q_OS_ANDROID conditional blocks in the QML, there doesn’t seem to be any sane way to use the (most closely) platform native style on each platform, I’d need to commit all the QML to using just one of them everywhere…
Which seems so absurdly crazy to me that my head is still spinning a bit at how much time I’ve just spent believing it could only be something that I was doing wrong which prevented this from Just Working - because all the documentation (with no actual complete working examples), so enthusiastically reassured me that this should be easy and painless and was guaranteed to be cross platform and work well on mobile… Which I really wish it hadn’t, and was a bit more up front about the current and very real limitations - because I would have much rather spent all that time, which I’ve just wasted on wild goose chases, actually working on fixes for known and disclosed problems to push upstream to fix some of these things. Instead I’ve spent it trying to reconcile the dozens of half-working examples which all do things differently and often incompatibly so, with what I’d tried to put together as a minimal working example - and wondering what kind of brain injury I must have suffered to not be able to see the mistakes in my own, otherwise very simple, code that were preventing it from working…
Anyway, I definitely don’t want to hijack this thread with my ranting (if anyone does want to follow up on that, let’s take it somewhere else and let this one get back to the oxygen integration) - I really just wanted to say thanks for the helpful replies and trying to make sense of that somewhat misleading warning, and tie all this back to We need your thoughts on Kirigami (which the ranty bit is more appropriate for : ).
