Splitting Kirigami into Submodules
One thing that we ran into during the Frameworks 5 lifetime is that it is hard to define what should and should not be in Kirigami. This lead to some things being included that maybe should not have been. However, to do that in the current situation, we would need to define "What is Kirigami" for all of Kirigami, which is hard. So rather than trying to define that, I had the idea a while ago that it might be better to split Kirigami up into smaller submodules, with each submodule having a clear defined purpose. This would allow us to more clearly say "this belongs here" or the opposite. Additionally, it makes it easier for developers to pick and choose what they need and hopefully also reduces the dependencies between different parts of the code.
We discussed this during the Kirigami BoF at Akademy 2023 and generally agreed that it would be a good plan. We also discussed in what way we wanted to split things and this is so far what we came up with:
- Primitives
- Primitive Items, that is, things that only inherit QtQuick Item or even QtObject, are not opinionated and generally just provide some sort of basic thing. Generally don't provide their own styling. Only depends on QtQuick. Things planned to be included: ShadowedRectangle and friends, Icon, Separator, ListItemDragHandle.
- Controls
- Single controls that inherit `Control` or `AbstractButton`. Mostly unopinionated, provide default styling but can be restyled using the usual Controls customisation process. If there's no existing QtQuick Controls template that can be used a template should be provided in the separate "Templates" module. Should only depend on QtQuick.Controls and things from the Primitives module. Things planned to be included: Card, Chip, Action, ActionTextField and derived controls, Link/UrlButton, PlaceholderMessage and LoadingPlaceholder, ListSectionHeader, SwipeListItem.
- Layouts
- Non-visual items that are dealing with placement of items. Unopinionated, should provide customisation points for anything opinionated that needs to be done. Should only depend on QtQuick.Layouts and things from the Primitives module. Things planned to be included: FormLayout, ToolBarLayout, PageRow(?)
-
- Dialogs
- Visual items that pop up over existing contents. Fairly opinionated, as these mostly implement behaviour specific to KDE software. Should mainly depend on QtQuick.Controls and the Primitives module. Things planned to be included: Dialog, MenuDialog, PromptDialog, OverlaySheet.
- Platform
- Platform integration facilities and types that are used to get information from the platform. Should not contain any visual items. This includes a library to provide platform-specific implementations of some of these types, what used to be "libkirigami". Things planned to be included: Theme, Units, InputMethod, VirtualKeyboard, TabletMode
- Framework
- Higher level components that are meant as an application building framework. Will often include types that combine a bunch of controls in certain ways. Very opinionated, it basically defines the "Kirigami" application style. Can depend on anything else in the Kirigami module. Things planned to be included: ApplicationWindow, ActionToolBar, Drawer subtypes, InlineMessage, Page types
- Templates
- Behaviour-only implementations of various controls that are meant to be overridden by styles.
This won't magically solve all our issues with "what goes where" but should at least make it simpler to determine if a certain thing should be included, especially with some simple rules about what things are allowed to depend on. Other than that, we should probably come up with a rule like "should be used by at least three applications before being included".
One thing I didn't discuss but which I would also like to propose (and I saw others already do the same) is to add some kind of "labs" module, as a place for API to mature. We have seen several things in Kirigami be either completely thrown out because the API doesn't work properly or things that are awkward to use. Having some place where we can say "this API may still change, but please try this thing" would be very useful for things to be included faster. I do suggest we come up with some kind of rule like "a final decision needs to be made 6 months after the first release with it included" or so, to prevent the labs module from turning into yet-another dumping ground.