 Welcome to yet another talk by really, really cool people. One is a little bit less cool, but he's a really great guy, Thomas. He's way cooler than me. And a bit more cool than, and also a really nice guy. They're going to talk about Kirigami with a really fancy title that they will pronounce. Yes. Great. So, I am going to say a dirty word during this. See if you can spot it. Well, the topic of the talk is about folding your applications. And the reason it is that is because we are talking about convergent applications. No one's noticed. Okay. So, the first point is we'll, yeah, quickly introduce ourselves very quickly as I understand it. I'm Dan Maynard, Arthur Jensen. And I've been a member of KDE for many years. And I'm a member of the Kaleegra and Gluon teams currently and have been a member of many other teams before that as well. Sorry, no, the Kaleegra and Discover teams Gluon is history and a leftover from a previous talk. I'm also an employee of Blue Systems and normally don't look like a blue bird. Yeah. I'm Thomas. I'm, yeah, I've studied psychology, focusing on human-computer interaction, use experience. And through that, I've come to KDE in 2008 and have been doing mostly, yeah, usability, use experience things since then as part of the KDE VDG, the design group. And since last year, I'm also a member of the board. I'm not paid to work on KDE. My day job is at Flare Games. Where you get to help Chuck Norris, a bunch of people, I think. Right, so, oh, yes, this was yours. Oh, yeah. Yeah, so first of all, what is Kirigami? Well, probably already heard about it because quite a few talks have actually mentioned it. It is a framework which, yeah, is useful to create touch-optimized applications. But that doesn't mean that they're only for touch devices. So as I've already said, it's for convergence. So Kirigami is your tool of choice if you want to create an application which runs both on traditional desktop computers with mouse and keyboard, but also on touch devices, mobile, embedded, whatever, with essentially the same code base. That's the key part. Yeah. And it is also a means to implement very specific human interface guidelines. We often get asked, why can't I create an application following exactly the Android material design guidelines, for example? And then usually our answer is two things. One is, well, you can, if you create an application that perfectly fits material design, then you cannot really use the same code base to deploy the application on desktop Linux or on iOS or on any of the other systems because then they would feel alien there even more. And would not be, or you would have to create different UIs which would not be consistent. Whereas Kirigami, we have our own human interface guidelines with some specific interaction design concepts which do diverge from what, for example, material design and iOS do, but they also have a lot of baggage from time, for example, when phones were still smaller and you could still easily reach the whole screen with your thumb, whereas right now you have large phones where your eyes should be more bottom heavy because that's what you can reach with your thumb. Yeah, it is a supporting technology, so what Kirigami does is offer you some building blocks for your application to create an UI easily which is consistent with other Kirigami-based applications and consistent across platforms. So it was born out of Plasma, so it was originally created to have something, actually for Plasma Mobile, but it is not only Plasma, so the same application can also run on, for example, Android, on iOS, and of course if you run it on a desktop computer, it can also run on any other desktop environment, it can run on Windows, it can run on Mac OS. Yeah, it was originally started as separate from KDE frameworks for the simple reason that the Qt version that Kirigami needed was higher than the one that KDE frameworks depended on at the time. By now this gap has been closed and with KDE frameworks 5.37, Kirigami will be an official part of KDE frameworks. Yeah, next up. Great, yes, that was mine. Right, so when you create a Kirigami application you have two options. The most important point here is that you have to have a container to host your application. And for the longest time that was called application window, which was basically a minor change on top of the Qt Quick controls to application window. These days, which will become apparent slightly later when that's important, we also have a thing called an application item, which simulates the application window API. Unfortunately we couldn't derive from it because that would make it a window and that would be bad because you'd end up hosting a window inside a window and that's a bit ugly. But what the application item slash window does is it implements some of the core user interface elements, which we will show you slightly later. It adds properties for inserting the user interface elements that the HIG defines as properties on this but it is very straightforward to construct the application without necessarily having to specify what edge something has to sit on or whatever. It also provides a very convenient method for showing passive notifications, the little toast things that you see on Android and iOS and so on, also recently on various other desktop applications, passive notifications which don't really have any kind of interactivity with a small caveat, but the purpose of them basically is to not do anything other than give you information. You're not supposed to do anything with them. And so the organization of an application in Kirigami is conceived as a scrollable row of pages and pages are what we'll mention next. As already mentioned, a typical Kirigami application is divided into pages. Usually on mobile you only see one page at a time, whereas if you scale up the same application to a desktop computer, you may very well see multiple pages in the form of columns in your UI. If you use the page class, then you already get all the standard behavior that the human interface guidelines describe. And one thing that makes it easy is that you have actions properties, how they are going to be visualized, we will see later, but you have a main action which will be the most prominent in your UI. And so this is in a button which is on the bottom center and it can also have a left and right wing or sub button because of secondary actions, which you can also just define in the page and they will automatically show up and be usable. And it can also define contextual actions, and these will then be shown in a contextual drawer, which I will also get to. Then something that you are likely to also use often is so-called scrollable page. So often it's lists of items or maybe just layouts which are too long for one screen, so you want them to be scrollable. And Kirigami also makes that pretty easy. And so you don't need to handle all the flickables yourself. The scrolling page will do that for you. And it also has nice things such as if you have a list, which you can refresh from some network source, for example. You can do the pull down. So if you scroll to the first item of the list and then you pull down further, then it automatically refreshes to give you newer items. And also something that was, an idea that was introduced in iOS at the point when phones became too large to reach everything with your thumb is that you can pull down the top of your UI so that everything that was at the top moves towards the center and you can reach it with your thumb. Right. And then we have the drawers, which are basically items which sit on top of everything else. They are a convenient way of giving you access to actions and supporting content to help with the things that are inside the page. So their base class is overlay draw, which allows you to, if you need something that is not supported by the core elements that we've got mentioned shortly, you can create your own as well, which is quite useful. It will attach to any edge and it was originally created because Qt Quick Controls 1 didn't have a draw, but not a draw of the way that we needed it. But these days it is, if you are compatible with the one that exists in Qt Qt 2. We also have a specific implementation of it, which allows you to push it onto the screen. This is less important on a desktop where you are working commonly in a window that doesn't sit against the screen edge, but if you are working on a pure touch user interface, say a phone or a tablet on incidentally any kind of platform, not just Android and iOS. This is also a problem on Ubuntu and on Windows. You need to be able to swipe it onto the stage. So you can do that on some of these platforms, the ones where those edges are not taken up by the system, you can do that by simply swiping your finger along the edge on the screen, but we have specifically Ubuntu and Windows 8 and 10, where that's not possible because that means on Windows 10 in particular that you suddenly are in a different application, which then meant that we had to come up with a way of making that easy to get to, which means we've now got a hook sort of gesture where you push up from the bottom of the screen and then pull to either side to show the corresponding drawer. Yes, so I think the next one is yours, but let's see. So by default there are two drawers, the global drawer and the context drawer. The global drawer is sort of the main menu of the application. It is very similar to the menu drawer that you have in many Android applications. And it slides in from the left, so either by an edge swipe, or there's also a little handle that you can use to open it. And it has a big fancy title where you can put an image in the background and make it look even nicer. And it has a main menu, which can also have multiple levels. And then you can also put in additional controls. As you can see here, you can also put in checkboxes, sliders, whatever you want. The global drawer is used for everything that is the same at any point in the application, so that users know that whenever they open the global drawer, they know what's going to be in there, they know what they can do with it. In contrast, the context drawer, as the name suggests, is dependent on your current context. So for example, it can have controls that apply to the current element that you have selected in the main view, or it can just change depending on where you currently are. For example, if you have a document viewing application and you have controls that depend on what kind of document is currently open, then these will be shown in the context drawer. And as you can see, it's also the elements are aligned to the bottom so that you can easily reach them with your thumb when using it with just one hand. Yeah, but then there are also custom drawers, as already mentioned, so you are not restricted to these main drawers. So the global and context drawers are very easy to implement because they're pretty much already there. You just have to fill them with things. But you can also use additional drawers for any arbitrary use you have. For example, a bottom drawer can be used as sort of a dialogue which is in material design and called sheet. So when you have something where you want to give users quickly some kind of some way to react to something, you can use a drawer so you don't have to replace the whole main screen. And then there's the overlay sheet, which, yeah, is better suited for when you have larger content. So the big advantage of that is that you can scroll even within the sheet. So one sheet can be larger than the screen height. Which means, yeah, you can show additional content on top of your main content, but people can still scroll through it. But then once they have reached either the top or the bottom, then they can just flick it away to close it again easily. Yeah, then one thing that I've already talked about, the primary action button. So if you define a primary action in your application window, then it will create a primary action button for you, which sits at the bottom center. So again, very easy to reach with your thumb. And you can just tap it. But it also serves as an additional handle for the drawer. So if you just press on the button but don't release, but instead swipe left or right, then you can also open the drawers with this, which is just a nice additional gesture. Yeah, but this is certainly mobile optimized, but the same actions on a desktop UI can go into a toolbar. So that is again something where Keregami helps with the convergence that you don't have to necessarily manually define everything that is different between mobile and desktop. The framework can do that for you. Yeah, another neat thing is the so-called swipe list item. So this is something where you have a list with contextual actions to the specific list items. There's one way to do that, to implement that is using the context drawer, but if you often have something that you want to do quickly with a list item, then a better way to do this is that you have a little handle on the list item, which you can just swipe away to reveal controls beneath it. Yeah, which gives you a very, very easy way to quickly do things. For example, if you have, let's say, a list of items, then you have things like delete the item, or if you have a list of emails, then you can quickly reply without having to open the full email first. The application header, so this is the title of the page, but it also doubles as a breadcrumb, because as we've already said, the typical thing that you do in kigami is using pages, and as you navigate through the pages, the application header creates a breadcrumb, which is interactive, so you can easily go back to any previous page by just tapping on it in the header. So there are, this obviously is not everything, this obviously is not everything that exists, so I'm going to rush through this for a bit. There is more stuff in kigami. We have a class called an action, which is kind of similar to a queue action, but which can be used more pleasantly in Qt Quick. We have list items which are not the swipe list item, so if you need something which is just a list item, you've got access to that as well. The item view header, which I will show you momentarily, which makes things pretty, and we've got a heading and a label which are semantic markup for text, just pure text. We have an icon which basically emulates the queue icon loading system without using a queue icon loader, and we have the toolbar application header, which is the thing you saw just before, which basically means even if you are on a mobile, you can still use the toolbar if you particularly feel the need to do so. So it's the thing that you can choose to do. We suggest you don't, but you can. And then there are a few applications which uses kigami. One of the first examples that we had was subsurface mobile. Subsurface is a dive log application which was started by Linus Torvats and Dick Hondle, and they wanted to create a mobile application. They had just recently switched the desktop application from DTK to Qt, so of course now they didn't want to learn yet another technology. They wanted to use Qt there as well, and then we told them, hey, we are currently creating that framework. It could be useful for you because it will make things a lot easier for you, and since then there has been a quite good collaboration with the team. They have given us a lot of input. We have helped them. They have given us ideas for new features, and yeah, both have benefited a lot from this. It's always nice to have external customers when you're working on a product, right? Here's one of our own, and it shows you the ListView header which makes things pretty. I realize I just forgot to scroll one of those screenshots because what it actually does is when you start scrolling the page, it will not be that big, which is useful. You will have run into this on Android and iOS in various places, so you start scrolling the list and the header stays visible but becomes really, really small, so it's not in the way. This is obviously discovered. You've probably run into that one at some point. This is Peruse, a somewhat smaller project, which looks a little silly right now because it is in the process of being remade somewhat, but it is an application which aims to fully implement Kirigami as a HIG, describes it, and function on both mobile and desktop with as few changes as absolutely possible for reading your comics. Then we have the very early stages of Kali Redim and I2, which was the reason for the creation of the application item because as much as this just looks like a straightforward Kirigami application there, what it actually is, it's sat inside another main window which will switch between a Q-Widget-based UI and a quick-based UI. Which is the Gemini thing. If you've spoken with me for the last couple of years, you will have heard me talk about this at length so I'll not do that here. There are other applications out there that are not ours purely, or some which are really ours, which is ClimbGrade, which is Marco's own. You will notice an overweight of extreme sports here. We have Koko, which is an image viewer project which has a summer code project to port the UI to Kirigami. It was originally written back before Kirigami was a thing, and we have Rukala, which I learned here, is also getting a Kirigami UI. And of course, all of the projects that you guys are working on. So please come talk to us, which is probably not now, I understand. But yes. So let's have at most two questions and let Kevin prepare. I have sort of a really nerdy question, but it's hard. What's the ratio of QML code to C++ code in the implementation of Kirigami? There is very little C++ code. The icon thing, I guess. Yes, the desktop icon thing is pure Qt code. It's all Qt code, pure C++ code, because we needed that to do it in any way efficiently. There is a non-C++ implementation of it, but I think it was originally written because of subsurface needing it, but it's usable in any application. So if you don't want the C++, or if you don't want all the abilities that the desktop icon implementation gives you, there is another option as well. It's a very, very lightweight thing which just loads icons out of a QRC. So it leads to a second question. Based on the blog from the guys, the kid guys, I think two weeks ago, about the performance in C++ and QML, how are you willing to think about changes, maybe some parts of the components in C++ just to improve the performance? That is essentially what we've done. So the really, really performance-dependent bits are done in C++. It is surprisingly minimal, but the performance there is, yes, that's why certain bits are done in C++, but there isn't a great deal of it. So most, a lot, yes, actually, he will know a lot more. Okay, quickly. Yes, just very quickly, as more recap on this, so basically now it's called Kirigami 2 because we basically re-implemented it completely from base to directly queue quick items to base on top of Qt quick controls too. So the amount of QML that has been instanced is already way less. That blog post was very interesting and what I would hope it comes out of that is Qt quick controls too, getting at least a bit of public C++ API and then at that point we can even go further doing some of our controls as actual C++ subclasses of Qt quick controls to classes. Okay, that's all the time that we have. So let's give a warm thanks. Thank you very much.