 I've become a cyborg, so I've got an antenna on my back to see if that works. Right, so, first of all, a few introductions to... Guys! Guys, nobody can hear! Thank you, sorry. A few introductions first. First of all, it's me. I've been with Katie for some time. And got my master's degree in writing some Katie software, which was lovely. And most recently, I've been a member of the Collegio team, and before then a member of the Gloon team, which is not very active anymore. And most recently became an employee of Blue Systems, where I last year presented an Android runtime that some of you may remember. And most recently have been working on this, which is a Qigami-based application that is designed specifically to do nothing but read digital comic books. Digital comic books, not unlike ebooks, have some fairly specific requirements for how to read them, which means that it doesn't really work very well in something like, say, Ocular, which is a generic, very powerful document viewer. There are some interaction methods that simply don't work very well, and which something like Peruse can do, because it doesn't try to do everything, it can do that a little bit better. It reads, amongst other things, the comic book archive format. And one of the problems that we currently have is, well, people need to get these things, which right now means going on to some very dodgy websites, or use nets, or various sort of things like that. It's sort of not very pleasant that whole ecosystem. There are locked down stores out there right now, which are things like Comixology, which is very, very proprietary, and not only do they not have a, there are problems in that one, which are things like their monetization format is a little bit heavy if you're an independent publisher. It's sort of rather heavy-handed. I've heard horror stories of 70% of revenue going to the distributor on something like Comixology. And obviously, that's a problem in itself, but it's also a problem that there's simply no access to that sort of thing from outside. So we have to work out a way of doing that. So we have this thing called the Open Collaboration Services. If you've been here for about half an hour, you'll know exactly what that is. Well, you'll also know it if you've been a KDE user for over the last 15 years, you will have seen these various little bits. Oop, wrong one. That's the KSTARS, which will download all sorts of interesting things, new star field catalogs and so on. But you'll also get all of those little star buttons all over the place. And you already know them. You've already used it. And when it comes to the technical side of this, everybody loves to hate this thing. There have been several attempts at replacing it with something else, and they've all failed. And these days, obviously, Seba's already spoke about this. The main implementation of that is now, yeah, it is officially now a KDE project. And this is really cool. It means that we no longer have those, apart from the minor technical issue that some people just don't like, the particular exchange format that exists for OCS, which is, yes, there are technical problems, but it's a web API. There are going to be technical problems there. Let's move on from that for a bit. So we have some technologies in KDE that have been working rather well for this for some time. The first one is the very low level bound directly and rather tightly to OCS, a Qt-based C++ library called Lib Attica. It's, as it says, the official C++ testbed for OCS features. If a feature is implemented in OCS, the standard that is OCS, it has to be employed both on a server implementation and a client implementation. And since inception, Attica has been the one that did that on the client. It is, however, a little bit heavy. If you want to do very intricate things, it's very powerful, but if you want to do, well, essentially things like putting those buttons on a dialogue to get hard new stuff, it's really awkward to work with because the boilerplate is the same size for any small amount of work you want to do. So, hence, OK, new stuff, which sits currently in tier three. It's currently a QWidget-based. And, yeah, it's very, very simple, very straightforward to use. You add a new stuff button to, yeah, that one, the button. You can access the other things as well, but really the button is the one that most people use. And you just add that to a dialogue and off you go. Obviously, you have to have content on the server to be able to use that button for anything other than showing an empty dialogue that says there's no such categories, but, yeah, it's a button and a config file if that's four lines long and then you pretty much got it. It's very, very straightforward to use. What it is, though, is obviously, yeah, it's one of the heaviest things to include any application, mostly because, yeah, so it includes Keo, which in itself is not too bad, but it also includes, yeah, the text widgets and widget add-ons, not too bad either, but XML GUI pulls in everything, literally everything. There is no tier two library that isn't included, which is great for Katie applications because we've been used to this for some time. Katie application, generally speaking, will run on a Plasma desktop and that already pulls in most of the dependencies and that's all right. But not so great for other people. Say we want someone who writes a pure Qt application or a mobile application or whatever to use the new stuff functionality, it's really heavy, it's very, very heavy. And we also have people who may not, may want to be in places that are not necessarily a Plasma desktop on Linux. And some of these places are also places that are not necessarily widgets. So what we're working on now is the splitting up of this, which we will, eventually, we will have three frameworks. And I know that there are going to be people who run packaging and distributions who will be shouting at me for this. They all hate when we split up our framework into micro frameworks and I believe there was an atomic int somewhere framework. Was that? No, int that zero. Int that zero, yes. Right, so, but I believe that this is one that actually needs to be split up because what it allows us to do is take all of the strict widget-based functionality that we've got in Canew stuff now and split that out into its own thing. Because it is already a released framework, we have to retain binary compatibility. Luckily, the Canew stuff framework is so pleasantly designed that that has been really easy. So as it sits in the branch right now, it installs on a system and it doesn't break anything at all, it just works. And that's with what comes next. Some beautification and so on, but all the API in any real way stays the same. Then we have split out the core. As it says, we can't actually put it into tier one because there are some still some frameworks that we depend on, but it's a very low dependency tier two framework. Then the new framework, which is Canew stuff quick, which is a sister to Canew stuff, which possibly would have been renamed if we didn't want to retain both binary and source compatibility, which is obviously... So we have Canew stuff core and we have the widget one, which is Canew stuff and Canew stuff quick for anything based on Qt quick. So in Canew stuff core, we have a load of stuff that already existed as convenience functionality that was used in Canew stuff. That was great. Yes, a bunch of models and the engine and the cache, which is possibly one of the more important things right now. There is no way of loading any of this offline. You have to have an online connectivity to be able to see anything that you've got installed which is a problem if you want to just uninstall something that you've installed. You have to be online to be able to check the current status of that one on server. Then we have the new stuff quick, which is just a straightforward Qt quick API in the way that Qt quick APIs must work. There are two ways of using this. Either you use the currently Qigami, probably will just remain Qigami based list components, which are essentially the Qt quick equivalent to using KNS button. The simplest possible thing you can do and you end up with something which will list things that are available on the store in the categories that you want. In this case, it is Plasma Tube, Yamaha, and so on. Those are Plasma widgets. It just will let you install and rate and so on the various bits that exist in that and it all looks the same, so very equivalent to KNS 3 button. Or you can use the API directly, which is where the more interesting opportunities start to happen. What you've got here is the first one was this is where you would get comic books, but obviously if you already downloaded a comic book from a series of comic books, what happens when you reach the end of that comic book? You want to be able to keep reading that. There might be another chapter in that series. It's been published since you downloaded the most recent one and that would then be able to show up in your list of what to read next. That's not something that would fit very well into a sort of standard API. Obviously, this is comic books. This is very app specific. We need to be able to access the model directly. We need to be able to check what's installed, what's not installed without being tied to using a specific set of user interface components. That then is what this splitting up bits is for. We have some samples. First of all, a quick little rundown of what we've got. We've got Attica, which is very powerful. We've got Canewstuff Core, which does most of the stuff that Attica does, except much more easily, much more simply, and covers most of the core use cases that OTS suggests. Then we have the old-style Canewstuff and the new Qt Quick stuff. Now, Attica and Canewstuff, those already have very good documentation as it exists. I'm not going to talk about them, because those samples exist already. Canewstuff Core and Canewstuff Quick have some bits. What you can do with Canewstuff Core that you can't do currently with the Canewstuff exposed API is something like this, which looks a little bit silly. You always have to create an engine, which you initialise with your KNSRC, which is a file that describes which provider you have your content on. In most cases, that would be the OpenDesk.default1, but it also defines what the categories you want to access are. What that then does is that, in combination with getting the cache for the application peruse, this is actually a little bit silly. Peruse currently will look for wallpapers, because we don't have a category yet on the store, which provides comic books. The cache for peruse is told through this bit. The engine has a number of providers, which are just string IDs, which are the same as identified in the cache. We go through all the providers, then we ask the cache that we got up here for the registry as it exists, for that provider, and then we list all of those entries for the provider. Those of you who have worked with KNewstuff before will notice that that doesn't exist. That's changing. That currently literally was not a possibility. That's now becoming a possibility. The offlininess of KNewstuff wasn't really a thing that was considered important before, so that's now being fixed. The quick stuff, to show how simple that is, this is way more of a boast than it needs to be. Those message bits don't really need to be handled. All you need is that line, and that line and the config file. Then you end up with something that looks like that and will install and remove and rate and everything. Very much like KNS3 button. Very simple, very straightforward. If you're using a Qt Quick application and just need to be able to install some stuff, that's all cool. You can also use this stuff directly. Because it's Qt Quick, you've got access to the models. You don't have to use all of these components. If we take a hypothetical, your own component, which will take a bit of text, it'll know what sort of things to do with an image URL. We know that the previous small bit of the model is a list of pictures, which may or may not have any entries. The CURSE lists in Qt Quick might crash if you try and access something that doesn't exist. We have to make sure that we don't try and pull an entry out of a list that doesn't have any entries. Hence, there's sort of awkward looking stuff there, possibly something we can fix. Then we want to be able to put some kind of little badge on the thing that you've got. You get the status, which is an enum on the new stuff items model, which you can check internally in your code. Just because that's easier, if we say that you've clicked it, it can then check it like that. Basically, the idea would be that you wouldn't necessarily want to do that. You would do that inside your components, or you haven't got that handling there. Further purpose of a demonstration that I thought that was probably a bit more straightforward, and all you then do is you create your engine, you create your model, and then you use that model's content. Again, deliberately, very simple, very straightforward. So, what we then have is the ability to read comics. We have to lose. We have the ability to get hot new stuff. Yay, you put the name in the thing. Now, what we want to be able to do is to be able to get comics. That is the new quick get hot new stuff stuff, but we also have some comics that we want to have comics to be able to get some. The problem is, obviously, in any store, you need content. Some of you may remember this picture from many years ago when I stood on the stage in Tampara and talked about content distribution with Gluon, and hence also the Nego logo on that one. Essentially, the concept here is the same. Someone has an idea. We create that content. We help that person bring that idea to fruition. We put it on their web service, opendeskup.org, and then we can consume it. And we can go back again as well with reviews and comments and so on. And the author can then comment back again and everything. So, to be able to complete that circle, that's what KU News stuff next is. So, if anybody of you wants to help with it, we have a project on Fabricator that was created to further that. And thank you to Ken Vermette for pulling out all the stops in an hour he has created for me. And we have this little tiny, tiny tool so far called Perus Creator, which will facilitate the content creators of the world, with the ability to create comics. And now the comic book format is really, really simple. It is very literally a sit file with some pictures in it. The problem with very simple formats is this whole ad hoc-ness of them. So you can do them, but you want to be able to do them properly. So, something like Perus Creator which will make sure that the files are named in a proper way and that you end up with something which is actually consumable in a sensible fashion. And then comes all of the extensions with the fancy animation type stuff that people want in digital comics these days. That comes later. But for now, Perus Creator, very, very simple, will create some comics for you to upload to the KDE store. So, yeah, that's where we've got to. So, quick questions. I think that's what I've written and said. I wanted three minutes for questions. Apparently, that's like tight, yeah, that works. Congratulations for your work with Ganyu stuff. Thank you very much. But when will you release Perus to Android? Pardon? When you will release Perus to Android? As soon as we are able to get Ocular working on Android, the PDF support, yeah, he's hiding behind a pillar now. No, right, so the problem we've got right now is that Ocular is the way we get, yeah, so the Perus will sort of read all the comic book formats and all of that, but it will also read PDFs and EPUB and so on. And the way it does that right now is by using Ocular, because we have this thing that will render all this stuff very well, but it's kind of heavy. So, if we don't want it, if we don't want PDF support and EPUB, if we just want CBR support, it wouldn't be an enormous amount of effort. But it would be nice. What? CBR support 127? Well, it's called, yes, that's okay. Why CBR and not CBZ? CBR is two things. CBR is Comic Book Archive, which is the format. It is also the sub-format of Comic Book Archive format, which uses RA to do the compression work. So, if you see a CBR, it is probably a RA file, but a CBZ file is also a CBR file. It's just using CBR instead. So, ad hoc formats are fun. But, yes, it will take a while before we get PDF support, at least on Android, but it will, yeah, through it itself will happen. Also because I have an Android tablet and I want to be able to read my comics on it. Thank you so much.