Lately, many apps are ported to Kirigami add-ons FormCard for about and settings pages. Has there been a design decision to develop KDE towards this “GNOME-ish” style? If so, why not change the “regular” Kirigami.AboutPage instead of introducing FormCard.AboutPage? I’m a bit concerned that this introduces an inconsitent look and feel within the KDE app ecosystem.
2 Likes
At least for me, I find it way easier to build UIs with FormCard than messing about with any other kind of method (especially with the new FormCard API making it even simpler - I don’t have to faff about with manual ColumnLayouts.) We know it isn’t ideal on desktop but I think it’s sort of at an impasse of how to make it more space efficient.
Some benefits I like:
- The AboutPage looks nicer, and will look consistent if the rest of the app uses FormCard as well.
- There’s an “About KDE” page (biased here, I made it) which Kirigami doesn’t have, which is nice to advertise KDE within our QtQuick applications.
- There’s lots of additional stuff included in FormCard delegates, like inserting inline status messages which I use all the time.
I’m not sure what you’re getting at here, they’re about the same feature set I think but FormCard.AboutPage uses FormCard components while Kirigami cannot. I’m not sure how you can bridge the gap here.
Yes it does 
There’s not an easy answer to that. It’s not like our Kirigami apps are seamless with their QtWidgets relatives in the first place though.
I’m a bit concerned that this introduces an inconsitent look and feel within the KDE app ecosystem.
I am concerned about that as well, and i consider it quite a blocker. converting everything to it will take again years, just in time for that look not to be current anymore, and also, in order for apps to really rely on it, either kirigami-addons is made in a real framework, or they are moved somewhere else that’s a framework
1 Like
The benefit I see to using FormCard now is the fact it has built-in inner layouts for most things, so it reduces ColumnLayout boilerplate.