{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigtm7k3zplwwayy6egxykfuxldrvrbkenyab73iwmt2fdrnkknkza",
    "uri": "at://did:plc:6dmfe46c76jjenq3kaxc5eds/app.bsky.feed.post/3mkqnnpazrq22"
  },
  "path": "/blog/2026/04/kirigami-forms-and-configurations/",
  "publishedAt": "2026-04-30T15:54:15.000Z",
  "site": "https://notmart.org",
  "tags": [
    "this"
  ],
  "textContent": "Recently a new submodule has landed in Kirigami: “Forms”.\n\nUntil this point, Kirigami had only offered the classic “FormLayout” component. which is used for configuration pages throughoug systemsettings, Plasma, and some apps. It’s the classical form used in desktop toolkits for decades:\n\nThis is a fairly clean layout which however is starting to slowly become outdated, as modern toolkits are starting to use a different layout nowdays, based on “cards”\n\nUnfortunately FormLayout very bound to the classic layout, and it wasn’t really possible to adapt it to the new look in a compatible way which didn’t break existing applications in unexpected ways.\n\nThis is also the reason a new approach was done provided by kirigami addons: “FormCard”, which is used by a lot of applications; for instance here in NeoChat:\n\nWe wanted to have this new style of forms in the base Kirigami API, so after a review of the existing FormCard, we decided to make several changes, for two main reasons: First, FormCard is bound to the card style of form as much as FormLayout was bound to the classic flat style. Also, it tried to provide ready-made components for every kind of control; so it had its own TextField, its own RadioButton and so on — effectively becoming its own separate toolkit.\n\nSo we opted instead to go down the route of having a more generic API, so the Forms module includes containers that define a semantic structure of a form, which contains all the normal controls — such as textfields, checkboxes and radiobuttons.\n\nThis is a code example of the new API:\n\n\n     import QtQuick.Controls as QQC\n    import org.kde.kirigami as Kirigami\n    Kirigami.Form {\n    Kirigami.FormGroup {\n    title: \"Global Settings\"\n    Kirigami.FormEntry {\n    contentItem: QQC.CheckBox {\n    text: \"Show Sidebar\"\n    }\n    }\n    Kirigami.FormEntry {\n    contentItem: QQC.CheckBox {\n    text: \"Auto Save\"\n    }\n    }\n    }\n    Kirigami.FormGroup {\n    title: \"Theme Options\"\n    Kirigami.FormEntry {\n    title: \"Colors:\"\n    contentItem: QQC.CheckBox {\n    text: \"Dark Theme\"\n    }\n    }\n    Kirigami.FormSeparator {}\n    Kirigami.FormEntry {\n    contentItem: QQC.CheckBox {\n    text: \"High Contrast\"\n    }\n    }\n    ...\n    }\n    }\n\n\nwhich will look like this:\n\nOr, in mobile mode:\n\nSemantically, a Form will contain one or more FormGroup objects, each of which will contain one or more FormEntry objects. Then a FormEntry will contain the control which represents the configuration of the particular thing. It can be a single control (like a button or a checkbox) or it can be any layout with completely custom contents.\n\nI already ported 4 modules of systemsettings to the new system: the landing page, the “workspace options” kcm, the mouse settings and the touchpad settings.\n\nBut wait… this page looks **exactly** the same as before; why?\n\nA key was to do an API that was as much as separated from any appearance as possible, as we don’t know how UI design trends will evolve in the future. But this also allows us another thing: to have two separate implementations: the new one “card based” and a legacy one which looks exactly like the current FormLayout components. This is used _only_ in systemsettings, so we can port all the kcms without introducing glaring visual inconsistencies, and when we are done, flick the switch and convert the look of everything all in one go.\n\nSince most of KDE’s QML applications already use the existing card-style kirigamiaddons FormCard components, the new look will be used there.\n\nAnd then in the future, when trends change again, we can re-style all the settings pages in one go.\n\n## A call to action\n\nWe ideally want the whole set of systemsettings kcms to be ported as soon as possible to the new system, so we can have soon a nice visual overhaul in the whole systemsettings.\n\nIn order for this to happen, we need the help of everyone, so… patches welcome\n\nAs an example, this is the merge request that ported the first four kcms.\n\nWhen porting, it’s also possible to see how the kcm will look with the new system as well, to make sure it works well for when we flick the switch. If we run in a terminal:\n\n\n    KDE_KIRIGAMI_FORMS_STYLE=cards systemsettings\n\nWe get systemsettings using the new style for pages already ported:\n\nPorting from FormLayout to the new Form/FormGroup/FormEntry system should be really straightforward; it should be possible to make good progress in little time.\n\nWith your help, soon KDE’s settings will benefit from greater consistency, a more modern style, and easier adaptation to future designs.",
  "title": "Kirigami forms and configurations"
}