 Alright, so I'm going to talk about an introduction to Kirigami, which is probably as relevant for the system contributors, but very interesting for new computers and app writers. So I'm going to talk about an introduction to Kirigami. First of all, I want to talk about what Kirigami actually is and what it is not. Then I want to talk about when you should use Kirigami and also when you should not use it. And then I will get into more details, what it actually offers, which is mostly going to talk about the page access that it has, then the various way actions work in Kirigami, and then some missed components that offers that help you create applications. And last but not least, I will give you some further resources on Kirigami. Okay, first, what is Kirigami? Kirigami is a toolkit for creating conversion applications. It is based on Qt Quick Controls 2 and it is a Tier 1 KDE framework, which means it has no other dependencies on KDE things. It only depends on extra CMake modules, which is like a build time only dependency and Qt. And since it's a KDE framework, it means it's released once a month and it offers API stability guarantees, which makes it nice to develop. And also in a way, it's a tool that helps KDE applications maintain a consistent look and feel, which is one of the goals that KDE set itself to foster a consistency between applications. And if every app uses Kirigami components, then it will magically be consistent. And when we change the implementation, then everyone benefits from it. What Kirigami is not, those are a few things that I've kept reading on the Internet, where I want to stress that those are not true. It is not a replacement for QML or Quick Controls 2. It builds on top of it and extends it with more higher level components. It is also not a mobile-only toolkit. Like the whole idea of Kirigami is to create applications that work great both on the desktop and on mobile and on things in between like tablets. It's also not the only way to create apps that run on Plasma Mobile. You can create great apps for Plasma Mobile with pure Quick Controls alone. You can also create apps with GTK or Lip-Handy and Lip-Handy, for example. They would run on Plasma Mobile 2, maybe not perfect, but that's something that needs to be fixed. It's also not tied to Plasma, desktop or mobile in any way. So apps written with Kirigami can run on other desktop environments and operating systems as well. For example, we have a lot of them running on Android. There's no reason why they wouldn't run on Windows or Mac OS, for example. And it's also not a style or a theme because Kirigami can work in fear of any Quick Control style. Okay, I think I skipped the slide on when you should use Kirigami, which is when you're writing an application with QML that should run on both desktop and mobile systems. And if you want to follow the KDE Human Interface Guidelines. Kirigami is not the right thing for you when you're not using Qt or not using QML, obviously. And it also may not suit your personal design needs for your application because it follows the KDE Human Interface Guidelines and thus has certain opinions on how things should look and behave. You may disagree with that and have other ideas for your application and if that's the case, that's perfectly fine. That just means that Kirigami in general or just some parts of Kirigami may not be the right thing for you. Kirigami can roughly be divided in two different things. One of them is the PageStack system that pretty much defines the overall application layout. And then there are random components that you can use in your application that will make them or will make easy to make them convergent. And the cool thing is that even if you don't use the general PageStack structure for your application for some reason, you can still make use of those other components in your app. So the PageStack is like the central element that defines the application structure. It consists of pages that you can push on a kind of data structure and also pop them from there. And those pages are kind of like screens where you go from one screen to another and then maybe back. So if you take for example a chat application, we usually have a list of ongoing conversations. And if you click on this list, then a new page gets pushed on the stack that shows the actual conversation. And the way they are displayed automatically adapts to the available space and thus to your form factor. So for example on mobile, there's only one page shown at a time. But on the desktop, it could be multiple. But to make it a bit more clear, let's check some code. So this is the most simple possible application here. Origami is just an empty application window. Now the most important line here is import.kde.ciriami which includes Origami in your Mellop so you can make use of it. And we start that it's just an empty application window. So now we have a first example of an actually made use of a page stack here. So every page has a title. In this case, it's my page. And then it has some content. In this case, it's just a little hell of a label. And closely like this, the base type for each page is origami.page. As a title set, and everything I put in here goes into the content of the page. And we put this into a component. And on the application window, we tell the window page should show the startup, which is sectored in the page property, which is set to the main page on it. Now, a single page is a bit bring. So let's put some other religious onto it. So here we would find a second page, a title of the content. And let's put a button on our first page. Can you assume your code please? So now we have a button here. And once we press that, the second page appears. And when we press those button here, the page disappears again. But otherwise, what we'll do is click the button for page stack.push with the second page component. And on the click button, that one clicked, we hit the page at the top to remove the page. So you see now we have two pages visible at the time. If I make a window monarrow, then the first page will disappear. But we can still between those two by clicking. Or as you see, we have now one component for each page. Which is a bit weird because we then would need to have all of our pages defined in one file, which is in general something we want to avoid. So what now would be a good step is moving out one of those pages into a second page. Which is done in the second page.qml file. You can see that the same content from before minus the component thing. And if you now open up external page.qml, we see that now instead of defining the whole page inside of the component thing, we can just make a new second page component, which is the same end result. But there's one way to make that even more simple, which is something I would have done live normally. But I will just push an updated commit. If you now go to the repository and just show the latest commit, then you will see my changes. Then what I did was replace this whole component thing at the bottom. And in the onClicked handler, just call q.resolve URL with the file name where my second page is actually defined. OK, so something we often want to do is pass some data from the first page to the second page. So for example, if we go back to our chat example, then we don't want to have, then we need a way to tell the second page, which chat it should display. And if you go to the page with properties.qml, that would be great. There we see how we can push properties from one page to another. Works like that. On our second page, we have a property label defined. And yeah, and then in line 18, we put another argument to the page.push call, which is basically a map of key value pairs that we passed there. So we set label to cut here from first page. And if you now run qml scene page with properties and press the button, we see that the text got passed from the first page to the second page. Yeah, I think that's all for the page stack. Then let's get back to the slides. So the next thing I'm going to talk about is actions. Actions itself are an abstraction over, this is something you can click or invoke or anything like that. You can think of it similar to a QAction object. It has a label or text. It has some icon. And it has a signal that gets emitted when you click on this action. In Kirigami, we have three different kinds of actions. First, there's global actions. Those are actions that are pretty much always relevant, no matter where in your application you are. So for example, going back to our chat app example, that would be settings, for example. Then we have page-specific actions. Those actions are only relevant on this particular page. We're currently on. And then there's context actions, which are somewhat similar to the page actions, but they are a bit less important and more secondary. So for example, in a chat app, a typical page action would be when you're on the list of chats, then starting a new conversation with someone. The way it works in Kirigami is we define the actions that we have that we want to have. And then implementation takes care of picking the right presentation depending on our form factor. So let's see some code for that. So first example is global actions. For global actions to work, we need to define a global drawer object. The global drawer is a drawer that appears on the left side of our application. We do that by creating a kirigami.globalDRAW object and assign that to the global drawer property of the application window. Inside the global drawer, there is an action property that is a list of actions that are going to be displayed. And each element is a kirigami.action, which has a text, an icon, and the signal handler that gets triggered when the action is triggered. So if you now run QMLC on that file, then you see on the top left corner, there is a handle that opens the global drawer, which contains our actions. And when you click on them, you see stuff gets printed on console. So this is the way it works on the desktop by default. So thank you. So now you see the handler thing that was on the top left at first is now on the bottom left, which makes it more mobile-friendly. But the actions are the same thing. All right, what you also can do is make nested actions, which then work kind of like a traditional menu that you see on the desktop. So here you see, we still have the two actions that we had before, the open and save. But now we also have a new action, which itself contains actions like a new text file or a new HTML file. And when you run this now, then you will see how that looks. OK, so on mobile, this is fine, I guess. On the desktop, you may think that having this kind of drawer thing that you need to pull out is a bit weird. And I would agree with that. So the global drawer offers a way for you to automatically turn the action or the menu you define into a hamburger menu thing when you're on the desktop. And you can do that by setting the isMenu property to true, as simple as that. And when you run the same thing on mobile, then you will see that nothing has changed. So that's an example of ways in which Kirikami adapts according to the form factor. And here is the application developer. Don't need to worry about that. So you may wonder now why this behavior is not default. And you need to opt in to do that. And that is because you can not only put actions into your drawer, you can put arbitrary controls in there. And that's what the fourth example shows. It still has these actions. But it also has a label set as top content, which will show some kind of title in the drawer. And if we would set the isMenu property to true now, then this label would get lost. And that's the reason why this is not on by default. So the way the global drawer is used in Kirikami apps and practice follows usually one of two ways. First one is the drawer acts as a menu, as we've seen before. But there are also use cases where this drawer works more like a sidebar on the desktop. And that's what the fifth example shows. Here we have the inline 12 and 13. We have modal and handle visible set to visible when not widescreen. Widescreen is a property that tells you if your window is wider in a certain threshold. And if you run this example, now we see that the drawer is turning into a permanently open sidebar thing. But if you make the window very narrow now, then it still turns. And there wouldn't be enough space anymore for the sidebar. It turns back into a drawer. And the mobile it also stays a drawer. So a user application developer has have the choice of either making it automatically into a menu or into a sidebar or by default, keep it as a drawer on the desktop. But that's not something I would recommend. OK, the next example shows the page action system. Here we don't have a drawer anymore, but instead we have three actions defined on our page itself. In Kirigami, there's place for three page actions. Most important one, or most central one, is the main action. But then there's also a left action and the right action. You don't need to use all of them. You can define none of them. You can just define main. You can just define left. And the way it works on the desktop is they get turned into a toolbar on the top, which you can see by running the example. So first we have the main action, which is edit. And then we have delete and share, which act like pretty much a traditional desktop toolbar. But on the phone, this would be not reachable at all. You cannot reach the type of your phone comfortably. That's why when you run the thing on mobile, the actions are displayed at the bottom where you can easily reach them. And now you also see where this left and right comes from. And the main action is kind of this floating action button in the middle. The next example shows context actions. Context actions are somewhat secondary. So you define them by assigning or putting them into the list and assign it to actions.contextual actions. And the way they behave on the desktop is by default, they are put to make them properly work on the desktop. You need to do one extra line, line 10. You need to set a context drawer on your application window. And now when you run the example, you see not much has changed at the moment in the presentation. But if you make the window more narrow, you will see that if there's not enough space, they get put into this overflow menu. The way it works is the tool bar is page actions are always put into the tool bar. And then when there are context actions and there is enough space, they get put into the tool bar as well. But if there's not enough space for all of them, the rest of them gets put into this overflow menu thing. And a mobile, the whole thing behaves different as well. So here we have similar to the global drawer on the left, we have a new drawer on the right that shows the actions in there. All right, so much about actions. So let's get back to the presentation. So next we have various components that are useful when creating applications. And you can use them independently from the PageStack mechanism. Our first one is kirigami.icon, which is basically it's just an icon that you can either load from your icon theme or from a QRC file or from any other file. Then we have several useful components when dealing with lists and how to make them more consistent and usable on the phone. I do have a code example for that as well, but we can show that later. Then we also have a CardsListView, which is somewhat similar to a ListView with the difference that lists are only suitable for a small amount of content, like one line of text and maybe an icon, but cards are larger and can display more content. Then there is FormLayout, which is extensively used in the system settings on the desktop. So this basically allows you to define controls like checkboxes or have controls like checkboxes, text fields, and have labels assigned to them automatically, and it's all laid out in a consistent way. Then also interesting is kirigami units. This defines some units that are useful for when you're dealing with building custom UIs. It defines things like a unit for paddings that makes the paddings in the application and in all key applications consistent, and it also contains units for animation speeds and times that are backed up by the animation slider settings in Plasma, and it defines a theme of properties that you can use to not hardcore colors in your UI, so they can automatically adapt to the current theme. So this is just a very plain ListView with 20 items, and as delegate, it uses a kirigami basic list item. Basic list item is an item that has one line of text and it has an icon, and this is such a common pattern that we have a component to do this, which then automatically applies a nice styling and makes it consistent throughout the KDE applications. The second example shows a list that has individual sections, and for this we have, so the model is not really interesting. It's just a few elements that are divided into sections. As a delegate, we have a basic list item again, and here as a section delegate, we have this list section header component that is just convenience for creating a nice-looking section header that's consistent with other KDE applications. You can see that everywhere in system settings, for example. And the third thing I want to show you is the swipe list item, which is a list item that contains actions that you can invoke, so a common example would be removing this item. So here we don't have the convenience of basic list items, so we need to define a content item ourselves. In this case, it's a simple label, and then we define a number of actions. So in this case, we have delete, and we have info. And here the presentation very much depends on whether you're on the desktop or on the phone. So here we see that when you hover over an element, you see the actions are selectable. And then when you click on them, stuff happens. There is also a way to make them always show, not only on hover. And on mobile, the whole thing looks very much different. Here you actually have those crack handles, and then you can use your finger to swipe them up, which exposes the actions, and then you can click on them. OK, let's get back to the presentation. So now a few resources for working with Kirikami. First of all, there's the API documentation on api.kd.org. It's not particularly great, so any feedback on how to improve that is very welcome. Box attract on the KDE-Buxilla instance. We also have a showcase application for what Kirikami can do, and also how to do that. That is Kirikami Gallery, which is an application that has all the features Kirikami has stuff inside and is a great reference for what it can do. And it's always worth checking out how to do it. The source code is not yet migrated to GitLab, so it's still available. It's still hosted on the old repository. And if you have any questions or problems, suggestions about Kirikami, then you can reach the developers in the Kirikami Room on Matrix. So that is it. Do you have any questions? Question is, can Kirikami work with over queued bindings like Rust, C-sharp, et cetera? So for the most part, Kirikami is only used from QML. So it doesn't really touch any C++, and thus it should work with anything that has QML support. So I've successfully used it with Python, for example. What's the recommended idiom when you need more than three page actions? Well, it's a clear sign that your application is too complicated and should be simpler. No, just kidding. Yeah, like Jonas said, the context drawer is the right thing there. I think the Kirikami source code contains a few examples. I am not sure what they do exactly, but they might be more suitable for what you're looking for. I think there is some tool that allows you to create QML in a way similar to the traditional Q designer, but I don't think anyone uses it, and people just write it by hand. I don't think many people use those design things. Pretty much all the people I know just write their QML by hand, which is fine because back in the days when you're dealing with widgets and UI files, you have these giant XML files that are super complicated. And there it's nice to have a visual tool to edit them, but QML is so concise and easy to write that you, in my opinion, don't need anything that saves you from that.