{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaz24mfcdxttt4gkvww63nn3gcebk4nr46jtv4hylnn6psrpqgscu",
    "uri": "at://did:plc:6dmfe46c76jjenq3kaxc5eds/app.bsky.feed.post/3mmcwcyhdizs2"
  },
  "path": "/blog/2026/05/kirigami-app-components/",
  "publishedAt": "2026-05-20T15:03:33.000Z",
  "site": "https://notmart.org",
  "tags": [
    "kirigami-app-componets,",
    "new repository"
  ],
  "textContent": "We just had a release of a new library, and future framework: kirigami-app-componets, which is a new repository where a certain kind of Kirigami extensions will go.\n\nThis repository will contain modules that are intended to be building blocks for applications to integrate within the KDE Frameworks ecosystem.\n\nWhy start a new repository when kirigami-addons already exists?\n\nWe now had a standalone release of kirigami-app-components with a single module inside for testing purposes, but the target here is to move it to frameworks releases, with all the stability promises and quality constraints of Frameworks.\n\nKirigami-addons is a bit more experimental of nature and have modules which, while they are a good first approach at solving a particular problem, would definitely need some work and refactoring for us to be comfortable having them in Frameworks, while other kirigami-addons modules will be a more straightforward import into kirigami-app-components.\n\nAn example of a module that was very useful but needed some work in its architecture is the StatefulApplication module (`import org.kde.kirigamiaddons.statefulapp`). It provides a Kirigami `ApplicationWindow` subclass and a way to map `QAction`s to Kirigami actions.\n\nThe central idea is having a series of actions that can have their keyboard shortcuts configured by the user (while also providing a component for such configuration UI).\n\nA problematic aspect of `StatefulApp` is that it’s based too much on C++: in order to add actions, it is necessary for the app to create a subclass and add them as `QActions`, then the QML part has to connect the `QActions` and Kirigami.Action using the proper API.\n\nThis is OK for the parts of the app where the logic is completely on the C++ side, but when it is necessary to add a very simple action (closing a page, opening a search dialog, and so on), this brings far too much boilerplate.\n\n## org.kde.kirigami.actioncollection\n\nActionCollection is the module that we introduce with kirigami-app-components. It’s all about collections of actions that are defined declaratively via QML (with the option of creating collections on the C++ side as well) and that have shortcuts configurable by the user via the standard interface.\n\nIn order to define a new collection, we would write the following QML:\n\n\n    import org.kde.kirigami.actioncollection as AC\n    AC.ActionCollectionManager {\n    id: manager\n    pageRow: pageStack\n    AC.ActionCollection {\n    name: \"org.kde.myapp.mainactions\"\n    text: i18n(\"Main Actions\")\n    AC.ActionData {\n    name: \"hello\"\n    text: i18n(\"Hello\")\n    icon.name: \"document-send\"\n    defaultShortcut: \"Ctrl+H\"\n    }\n    AC.StandardActionData {\n    standardAction: AC.StandardActionData.Copy\n    }\n    ...\n    }\n    AC.ActionCollection {\n    name: \"org.kde.myapp.photoactions\n    text: i18n(\"Photo Actions\")\n    AC.ActionData {\n    ...\n    }\n    ...\n    }\n    }\n\nThe ActionCollectionManager will be a single instance for the whole application, and it is what takes care of instantiating the common actions (such as About Application, About KDE, Configure Shortcuts, and so on) and doing the plumbing with the configuration dialogs and so on.\n\n`ActionCollection` is a set of actions semantically grouped together in the same category (if an application would have, for instance, actions that operate on photos and actions that operate on videos, those could be two different collections).\n\n`ActionData` is the semantic representation of an action (internally it is a `QAction`, so it has all its properties) and will be defined only once for the whole application. Instances of `Kirigami.Action` will be attached to it (even more than one), and those will define the actual buttons and menu entries in the application.\n\nA `Kirigami.Action` is attached to an `ActionData` via an attached property:\n\n\n    Kirigami.Action {\n    // Here shows how important is that each ActionCollection has\n    // an app-global unique name and each action has a collecion-global\n    // unique name as well\n    AC.ActionCollection.name: \"org.kde.myapp.mainactions\"\n    AC.ActionCollection.action: \"hello\"\n    onTriggered: {\n    // Logic here\n    }\n    }\n\nThe `Kirigami.Action` instance will not have text, shortcut, or icon defined, because everything comes from the attached `ActionData`. Only the `onTriggered` logic will be defined there (as well as the logic for when the action is enabled or visible).\n\nWhen an `ActionCollectionManager` is created, a collection named `org.kde.globalactions` will be automatically created as well, which also contains an action called `\"KeyBindings`“. When triggered, this dialog will open:\n\nThis is the configuration UI where it is possible to configure all the application shortcuts.\n\nAnother action called “`FindAction\"` is also available: when triggered, this other dialog will open instead:\n\nThis is the classical `Ctrl+Alt+I` dialog also present in QWidget applications, where it is possible to search and trigger all the application’s actions.",
  "title": "kirigami-app-components"
}