OK, maybe good to start some playground topic which involves ports not landing (yet?) in the depot.
Some of these may be experimental and not ready for public releases, or not even functioning in a way it’s usable, but maybe could bring someone else to ideas and start patching them to be ready for the public.
I’ll start of (did already a few teasers in the New/Updated … topic) with Alligator, a “mobile” feed reader for KDE.
Although it’s working fine for me on 64bit, I can’t get it to launch properly on 32bit (with KDE frameworks 5.93.0).
I have been looking into bumping the KDE framework to 5.112.0 (latest is 5.113.0~rc1 at this time of writing), not ready for release as I think I still have some errors on runtime for some applications build against it (so I leave that one to the master)
EDIT: this is the error when trying to launch if on 32bit:
file:///boot/system/data/Qt5/qml/org/kde/kirigamiaddons/labs/mobileform/AboutPage.qml:9:1: module "org.kde.kirigami" version 2.20 is not installed
It’s a bit funny seeing the half-Breeze, half-Haiku stylings of the Kirigami-based apps. It is strange yet intriguing to see the Haiku aesthetic in interfaces that have animations and convergent design. Often makes one think what Haiku would look like with a mobile UX.
The second linked page has a list of links for the source code to various pieces, including Kirigami.
If you are building your own application from scratch using the source code for KDE Frameworks, perhaps you need to do some extra work? Or maybe you need to make sure the application is using the appropriate version?
kirigami2-5.93.0
^ note that this indicates “kirigami2” and “5.93.0” (I guess that’s the version of the KDE Frameworks).
I take it there is kirigami1 and a kirigami2 that are distinct from the specific versioning of the code itself. It’s unclear to me if the error refers to the code v2.0.0 or kirigami2.
It’s a distinct possibility that the build scripts/automation are not building a 32-bit version of something you need or placing it in a location that’s inconsistent with where KF 5.93.x expects to find it.
You can see in the above list of packages for various distributions that the package name/prefix is ‘kirigami’ or ‘kirigami2’ (e.g. kirigami2-dev, kirigami2-docs, kirigami2-lang, kirigami2-lib) with some occasional variations like ‘kirigami1’ or ‘kf5-kirigami’.
The one where this is working is using the 5.112.0 framework. On the other installations I checked there is the default 5.93.0 installed from the depot.
I believe there is, came across some information about this.
Perhaps I need to check those out! Currently we got 5.93.0 (and local 5.112.0) only.
So far I’ve picked up the sources from kdeinvent, so maybe for this I need to check further, thanks!
Kirigami is a set of QtQuick components for building adaptable UIs based on QtQuick Controls 2.
Its goal is to enable creation of convergent applications that look and feel great on mobile as well as desktop devices and follow the KDE Human Interface Guidelines while being easy to use and not adding many dependencies.
Kirigami works on a variety of platforms, such as Plasma Mobile, Desktop Linux, Android, MacOS, and Windows.
It’s super annoying when people refer to software that has different “branches” like kirigami1 and kirigami2 without being explicit about the branch used.
I realize that many software developers do not bother with backwards compatibiltiy and just leave a messy trail behind them, but it would be a lot less confusing if they were a tad more explicit somewhere.
I don’t know that much about HaikuPorts myself, but perhaps a peek at what’s over there would be good? If that would work for your development process it might be better than directly pulling the source code from the official KDE repositories…
If recipe updates are needed (and you aren’t the one that did the current ones), maybe you could look into that?
The most important thing at the moment is, I think, to make sure you know what the error is referring to.
Presumably the build process would like to find a bitness compatible (32-bit, 64-bit) kirigami2 module that is compatible with KDE Frameworks 5 (KF5). There may be other requirements/constraints, but I wouldn’t know.
I’m one of the maintainers of haikuports, so I know my way around there, I didn’t do the work on the initial KDE framework ports (that is still @3dEyes ), but played around with bumping them locally to the most recent ones. As mentioned in the beginning, probably not fully functional (I’m guessing there is something in KIO that is causing a crash on the latest kdevelop for instance) (not in Haiku atm).
I mostly check the cmake files on the KF5 requirements, for Alligator it’s still set to 5.90.0 (iirc), so that shouldn’t be the problem here, I’ll keep looking into it.
I think it’s safe to say that the older version (1.1.0 and 2.2.0) are pre-framework releases, a quick look into the cmake file mentions: set(KF5_MIN_VERSION "5.18.0") , so I doubt we would go back there.
And a new one, Kommit, a git gui for KDE (not tested on KF5 5.93.0 yet), merged into the repo now, still have some issues with “git rm” on this, first try-outs went fine :
I’ve tried drawing mobile UI concepts for Haiku but no one seems to agree what a ‘good’ one would be so I’ve given up imagining what Haiku as a mobile UI would look like
Nice one. It can be an horror to deal with those colours, indeed.
To be honest, KDE apps are not the worst as long as they don’t incorporate custom widgets. Otter has few that make things quite tricky, for example.
To be able to use it I had to add 2 new packages (kdecorations and breeze), the other ones I just grabbed from corresponding archives and copied the color scheme file to ~/config/non-packaged/data/color-schemes, on next launch they are detected by the applications. (so only the schemes, no icons etc added)
Is that possible - once in a future - to have a KDE menu item (and a folder as well with subfolders ) in Deskbar
under Applications
which contains applications ported from KDE - even categorized as it is on a GNU/Linux system ?
@KitsunePrefecture that talk has been done many times before, and yes, it would be perfectly possible to do this in a recipe, it’s then a matter of how to categorize those entries.
Kdenlive 23.08.5 has been released, so wanted to see how it still behaves, with one of the example projects coming along with the source, seems to be fine.
mumble is now working somewhat on Haiku. It’s working for the most part, apart from some window sorting problems which should now be fixed (the add server dialouge liked to appear behind the server selection dialouge which makes it look like it froze, you had to move the selection dialouge a bit) and some seldom audio problems (the sound that plays when you mute yourself sometimes plays incorrectly) which aren’t that big of a problem
But it works well enough. 
