 Yes, thanks, Luigi, and welcome everybody. So I'm going to talk and spend the next around 30 minutes, maybe a few more, talking just about recapping Qt 6, what led us there, what motivated us to do Qt 6, where we are with Qt 6.1 and a little bit of an outlook into Qt 6 as slightly beyond. Let's get going. To start with, when we're doing a major version update, it's always important that we think a bit about what's really the important thing in the tooling we're doing, what is the thing that's actually driving us. And for Qt, it has always been for all the 20 years or more than 20 years I've been working with Qt. It's been about making life easy for developers, making development of applications, cross-platform applications and then into embedded devices, fun and easy. Simplify that. That's the thing that has been driving us all along. And for Qt 6, we wanted to take the next step there and do some more changes that further improve this. So let's have a little bit of a look into Qt 6 and what has been motivating us there, things that we've been doing. But before we go there, let's take a little bit of a high-level view. For Qt 6, we had a couple of high-level goals and fixing certain architectural limitations that we have discovered over the years in Qt 5. We wanted to improve performance in quite a few places. A very important topic for us has been to clean our house a little bit, get rid of legacy APIs, old code, things that we don't want to use or maintain anymore. We wanted to try to see what we can do with package management support and have that better supported within Qt. I don't think we're quite there yet with Qt 6, but it is still something that's on our agenda. Make the core product, the core of Qt a bit smaller and more modular, maybe also allowing us to handle add-ons slightly in a different way. But then, of course, also very, very importantly that we are keeping the compatibility with Qt 5 as much as is possible. We also have a couple of important high-level values that we need to keep up and that's our user's value. This is the cross-platform nature of Qt that we are basically running on every desktop operating system out there, every mobile operating system and a wide variety of embedded systems. The maintainability, compatibility that Qt actually takes the burden of bringing your application to the next version of a platform away from you that we're trying to take that and that the code that you're writing is actually generically very maintainable over time. Scalability, you can go from very low-end embedded systems to complex high-end desktop applications, connected applications that span multiple devices, multiple large systems like that. APIs and whatever we're having on the tooling side should be intuitive and easy to use. We're proud of the documentation that we're having and we want to keep it that way. Having a world-class documentation is really, really important and the thing that got over the last year is more and more important for us is also the tooling. So a couple of high-level goals, as I said, cleaning up our code base and our architecture and not new features. That was the main goal for Qt 6.0 and is still the main goal for 6.1 and 6.2. We're not focusing that much on bringing tons of new features to you at this point in time, but rather clean up what we have and prepare it for the future. Nevertheless, you'll see some pretty cool stuff also already in 6.0 and more of that coming in 6.1 and 6.2. Compatibility, as I mentioned before, is really, really important for us. And we have a very large user base out there. KDE is one of the big projects that's using Qt, but we have so many other people. There are billions of lines of code that are written against Qt. And that means we need to make it easy to bring all that code over from Qt 5 to over to Qt 6. So we wanted to make sure that Qt 6.0 is as source-compatible as we can with Qt 5.0. There's still, nevertheless, some porting that will be required. And I think some of you who have been working on that already within KDE have maybe seen a bit of that. We have removed all the deprecated functionality that goes back to the house cleaning that we wanted to do and preparing ourselves for the future, which means you'll have to clean up certain pieces. But most of that can be done on top of 5.15, enabling deprecation warnings. We'll get you along where they are. And those changes really prepare us for now for the next years to come so that we can hopefully also Qt 6.0 can have a rather long lifetime. Let's have a little bit of a look at the large architectural changes we've been doing for Qt 6.0. The first one was to move over to C++ 17. That has been an important topic for us. We wanted to move along with the C++ standard and make sure that we can also use new features that are available in those new C++ versions. We've moved to C++ 11 with Qt 5.6. Now was the time to take the next big step and also start using that in our code, in our own code, but also modernizing some of our APIs to at least to some extent were possible to make use of modern C++ features. Let's start off at the low end what we've been doing on our containers. A large amount of work has gone into that area. A big thing for us was to look at Qlist and Qvector, the two containers that were doing similar things. There were some implementation issues with Qlist. Many of you might be aware of them. And we've now had a close look at those and in the end decided to bring those together to have one class in Qt for doing list-like operations. And Qvector nowadays is an alliance to Qlist. We've introduced 64-bit support for all the containers. So they're all using Qsize type now to store size-related and index-related information, meaning you can have more than two billion items in the container, something that was requested for a very long time for many of our users. Qhash and Qmap got completely rewritten. Qmap basically is now using standard map underneath behind the scenes and can actually be converted or moved to and from a standard container. Qhash, we have gone a different route and we implemented it completely on our own. I'll show you on the next slide a little bit why. And then we went in and filled lots of API gaps that we used containers, had touts, standard containers. Make sure we can consistently use move operations, and place ranges and initialize lists and other things. So with Qhash, we actually went back and did our own implementation. And here's a little bit of the reason why. We had a look at standard unordered map and whether that could be a solution to base ourselves on top of that. But what we found when we did some benchmarking and some measurements was that standard unordered map was performing rather similar to Qhash and Qt5. It was a bit better in terms of memory usage and consumption, but there are other hash tables out there who can do a lot better. And we went in and looked at that and then implemented a hash table that gives a very good compromise or gives us very good performance also for large hash tables and a much, much lower memory consumption than what we had with Qhash and Qt5. We were finished also another item that was only 80% done in Qt5 and that was its Unicode handling and all our string classes. In Qt6 now, all text handling is Unicode-based. We assume basically UTF-8 for data that we're reading in by default and UTF-16 for all our internal data that we're storing. Our source code, for source code we have by default is also assume UTF-8 and we've cleaned up all our string-related classes to make sure that we have now a consistent set where we added Qtf8 string view for UTF-8 encoded data and the view into UTF-8 encoded data. We had Qt string view already and completed that one, made it mirror all of the read-only API of Q string and deprecated certain APIs such as Q string ref. Finally, we also took the step to remove the legacy and coding support for out of Qt core. So Qt text code is not part of Qt core anymore. We have a Q string converter classes that can do Unicode conversions plus Latin one and local 8-bit. A second big topic for us was the support of bindings. Bindings are a concept that came and that we introduced in QML and Qt Quick. And that is probably the feature that made Qt Quick really, really successful over the last years. Having the ability to bind arbitrary expressions to properties and making sure the properties get up automatically updated whenever a dependency, something in the expression changes has proven to be extremely powerful. And with Qt 6, we wanted to bring that support down to Qt 6 to make it available to all of Qt and bring it to C++ so that when you're doing C++ development, you can use bindings the same way as you can use them in Qt Quick. Wanted to make sure that we have a seamless integration there with Q object and make it a simple extension of the existing property system. In addition, we also introduced a new Q property class which supports bindable properties also outside of Q object. Here's a simple example in Qt Quick. You can easily, if you define, for example, a rectangle and it has a property width, height and border and you can easily bind here the width to the height. So when you change the width, the height will get adjusted. It's actually a square using those bindings and it has a border that is 10% of the height and thus 10% of the width. And those relationships always hold. In Qt 6, you can do that the same thing in C++ and the code is rather similar. So we have a rectangle as a struct with three properties, width, height and border and then you can set up in the constructor, you can set up your bindings where you bind the width to the height to the width and the border to 10% of the height. The second really, really big change and new feature for us was redoing our graphics architecture. This is probably the one area in Qt where we've done a lot of work apart from Qt Core and the changes there. This is probably the area that has received most work there. And the reason for that is that the world has changed significantly since we introduced Qt 5 in this area. When we did Qt 5.0, OpenGL was the cross-platform API that you could use for 3D and hardware accelerated graphics. It was pretty much supported everywhere, even though it was to some extent a little bit of a second-class citizen on Windows. It was still supported there and you could get good OpenGL drivers on Windows. But the world has changed over the last couple of years. Apple introduced Map Metal as their new 3D graphics API has gone so far as to de-procate OpenGL. Vulkan has come up by the Chronos Group as a successor and Microsoft is focusing more and more of their work also on Direct 3D. So it was time for us to change that and introduce something that helps take this away because now we're having a situation where there are lots of many different APIs. And for us as a cross-platform framework, of course, the job is then to see how we can take that burden away from the application developer. So we added what a thin layer on top of those graphics API called the Qt Rendering Hardware Interface and build Qt Quick, the scene graph, Qt Quick 2D and 3D on top of that. In addition, we introduced a new module called Qt Shader Tools to be able to handle shaders in a cross-platform way. The Rendering Hardware Interface is actually a very thin abstraction layer for 3D graphics APIs, covering OpenGL, Metal, Direct 3D and Vulkan. And it abstracts multiple graphic, all the graphical objects that we need, materials, measures, shaders and so on. For the moment, it's an internal API tuned towards the needs of Qt. We are considering making parts of that public also in the long-term, probably QPA style so that we will not guarantee full compatibility between the minor Qt versions, but there is certainly a need for users to also be able to integrate with the Rendering Hardware Interface in the future. But for now, it's an internal API. Integrates with our platform and the window system abstraction layers. And Qt Quick, Qt Quick 3D with 6.2 also multimedia and other modules also Qt 3D are now fully ported to using that Rendering Hardware Interface. Qt Shader Tools is the complementing module that we need to be able to do that. It's there to support cross-platform shaders. The shading language is different, different between the different graphics APIs between Metal, OpenGL, Vulkan and Direct 3D. But with Qt Shader Tools, you can write the shader once in a cross-platform GLSL or in a Vulkan-style GLSL, and then we can recompile it to all the graphics APIs, both at build time and also dynamically at runtime. What's important to remember here is that Qt 6 now uses the native graphics API of each operating system. So whatever the graphics API is that your operating uses, we're using it by default. We'll be using Metal on macOS, Direct 3D on Windows, OpenGL or Vulkan on Linux and so on. This is really important and make sure that we can get the best possible support on all of those different operating systems. Qt Quick 3D is a module that we introduced in Qt 5.14, 5.15, but it has received a lot of changes and a lot of good things in Qt 6. We're now basically working on one combined scene graph for both 2D and 3D in Qt Quick, which means you can very efficiently combine 2D and 3D in one scene in your UI and then bet them into each other. We've extended and improved the support for PBR materials significantly and also made sure that we can easily import GLTF where we support the full base spec and most of the common extensions. The Quick 3D has also gained a lot of new features like a 3D particle system where you can do really cool animated 3D effects, instance rendering in case you need millions of objects in your scene and also things like mesh morphing animations are now supported. So you can easily connect that and hook that up in QML to the state changes of your user interface. Finally, we've been pushing for better seeming and styling of the Qt Quick controls. Qt Quick controls, as we have them in Qt 5.14, 5.15, were not really styleable. There was a little bit of some seeming support using PIX maps, but they didn't use the native style of the underlying operating system. That's something we've fixed now with Qt 6 and we have now native look and feel for Qt Quick controls on macOS, Windows and Linux. We're also planning on extending that into the mobile platforms now moving forward. And here, the longer term goal for us is, of course, also to make sure that Qt Quick becomes something that you can fully use also on desktop and mobile if you want it, even if you want to do native looking user interfaces. So we will be working on extending also the feature set of Qt 6 to cover those things. The reason here is also that Qt Quick is much more suited to modern fluid animated user interfaces than what we can do with Qt Widgets. For everybody who has tried to implement animations within Qt Widgets knows that this is a rather difficult job to do. It's tedious, arrow-prone work. Qt Quick makes that a lot easier and we want to make sure that all of our users can benefit from that also on desktop and the mobile platforms. We worked on the pointer event handling, touch event, mouse event, tablet events, and unified those in with one common base class called QPaint pointer event. The advantage here is that, and it solves the problem that we had before when in certain complex controls and use cases, it was really, really difficult to get all the use cases working with different events there. So, for example, a touch-enabled controls inside a flicker, they will always work with that, and we can do that much better now with pointer events. In addition, we are also now tracking the input devices' history of the event points, allowing you to be able to use that extended information in many use cases. As I mentioned before, another big topic for us is, of course, also the tooling around Qt, the developer experience. Qt Creator as the main developer tools is something that we've spent a lot of time improving on, on improving. And the developer tooling, of course, fully supports Qt 6 nowadays. We have wizards for Qt 6 compliance projects. You can inspect all the Qt Quick types in the debugger. We know about, the editor knows about the new QML and C++ language features. And of course, you also have inline access to the documentation and the examples. We've done also a lot of work in improving the C++ support, the generic C++ support in Qt Creator, with new and improved refactoring, refactoring tools, removed the Clang code model up to Clang 11, and had a much tighter integration now of Clazy and Clang Tidy. And finally, did also lots of other smaller changes just to improve that experience. And finally, of course, also in Qt Creator, we've vastly improved CMake support. We're having that there. A lot of the improvements come through the work that we've been doing, bringing Qt over and porting Qt to use CMake as its native build system, improving a lot of the CMake support for Qt, also upstream in the CMake project, and then also doing that integration into the tooling and Qt Creator. That's the second big tool that we're doing a lot of work on that's on the designer experiences Qt Design Studio. Qt Design Studio is a tool that's there to graphically create user interfaces and do all the UI work in a graphical tool. We've done a lot of work there to improve that. So one of the goals for us when we moved over to Qt 6 was to unify the design tooling. In Qt 5, we still had Qt 3D Studio as a separate tool for doing 3D UI design. It was also using a language that was different from QML. We've unified all of that. It's all built around QML as the programming language and this one unified design tool with Qt 3D Studio. You can now mix 2D and 3D content seamlessly there. Doing a lot of work to improve that further. One of the goals for us here with Design Studio is to improve the interoperability with Qt Creator. Qt Design Studio is in many ways Qt Creator. It's using the same application shell around it. It is basically just having somewhat different plugins and the different selection of plugins and some changes to the UI compared to Qt Creator. So that's going to happen and we have still a bit of work to do in that front. And we of course have a big goal of making sure that all our UI features and Qt Quick 3D are toolable. Now, also advanced things like particles, skeletal animations, and that we have a lot of low code features available there for the developers and designers so that you can visually program a lot of the UI logic. Things like shader programming tools, wireframe tools for 2D shapes and paths, all of those kind of things are things that we want to add to Qt Design Studio. Beyond Qt 6.1, what's happening there? What are we working on right now? As you probably know, Qt 6.2 has just recently gone into feature freeze and most of the work has been there focused around putting the remaining add-ons to Qt 6. Turn activity with mode objects. With 6.1, we had already charts and data visualization, many others. All of those are coming back in 6.2 and 6.2 should be to the largest extent feature complete in meaning having the same feature set as Qt 5.15. There's a lot of bug fixing we have been doing and working on making sure that we have stability and maturity. 6.2 will be the first long-term supported release for the on the commercial side as well. So we want to make sure it's as good as possible. And of course also make sure that the development targets then again match what we had in Qt 5 by adding integrity QNX web assembly and more embedded hardware platforms. A larger change that's happening with Qt 6 is that we're getting a completely rewritten Qt multimedia. I've been myself working a lot on that module with an easier to use API and hopefully a consistent cross-platform feature set. Qt multimedia has been, let's say, a module that was that we were never really happy with during the Qt 5 lifetime. And I think I hope that we can now with Qt 6 get something that's really good and easy to use and that also our users will be happy with Qt Web Engine will live a little bit more its own life with Qt 6. We will be working on decoupling it from the Qt 3 release cycles allowing it to do faster releases. Basically, always base it on top of the latest most secure Chromium and be able to use that latest Web Engine version with multiple Qt web versions. And of course, finally also Qt for Python is something that we're bringing along all the way and where we want to support everything there. So here's the list of the supported modules that we had. As you can see, we already had quite a lot of things available in Qt 6.0. In 6.1, we added another 7.8 modules and with 6.2, most of the remaining modules that we had in Qt 5 are then available as well as you see Bluetooth, multimedia, NFC, remote objects, serial bus, you name it. On the platform side in Qt 6.1 we're basically supporting Windows 10, macOS 11 on Intel hardware and Linux as development hosts. And then have also Windows 10, macOS 10.14 and newer Linux desktop and embedded as target environments on the mobile side, Android and iOS. And then finally, we're having on the embedded side Q and X in the category as tech previews. For 6.2, this is improving slightly and we're then also supporting macOS 11 on ARM on Apple Silicon fully, both as a development host and the target environment. We're fully supporting then Q and X and integrity and we're bringing WebAssembly back as well. Okay, and here finally, just to give you an overview over the release schedule, Qt 6.1 has been released in May. We're working on Qt 6.2 and hope to have it out in September this year. And then if you look closely, you can see that we're adjusting our release schedule slightly. We're continuing to have a six bi-annual releases every six months, but we're shifting them forward a little bit. We used to have them in usually November, December and May just before Christmas and just before the summer vacation break. We're now shifting that more towards spring and autumn with March and September. That is our long-term goal. Okay, and that brings me to the end of my presentation here. Thank you very much for listening and I think I'm happy to answer as many questions as possible in the remaining 10 minutes. Thank you, Lars. There is a lot of work ongoing and when you have to deal with a base library or base framework better, like Qt, so it's always complicated when you have to do breaking changes. But we have a lot of questions. So let's start. So from the Nicholas asks, we need one wide codec support in KDE to handle arbitrary data from the internet. Any plans for bringing that back in the future in some form? So first of all, it's not completely gone. The existing Qt text codec support is there in the Qt 5 Compat Library. So you still have that available. The plan for me for the longer term is or the change was twofold actually. One of them was that I was never really happy with the Qt text codec API and QString Converter, QString Encoder, Decoder has a much better API in that respect. For the long term, I think that and I've designed QString Encoder and Decoder in a way that we can extend it and basically add a little bit of a plugin infrastructure there to it so that it can support other encodings as well. Probably just using ICU as a backend there and where the plugin would solve most of those issues. Hasn't happened yet for 6.2. It's a little bit on the backlog right now because it's not that urgent for most people. There are very few applications that need the full codec support these days. It's basically an email application. When you're doing that, there might be still a little bit, the web browsers, but they're anyway doing their own stuff. And then it's maybe a text editor and that's where it ends. So it's sort of a little bit that corner case, use case these days. If you look at how much of the text and the data out there is unicode encoded these days. Yeah, compatibility is sometimes it's important. So the other, another very voted question from David is, would it be possible to create our own new style, quick control style? For us, fusion is not really native. I understand that fusion is not really native for KDE. I think it's possible. I haven't actually looked into the architecture. And I mean, of course we can certainly consider how to do that, whether you wanna do that as a plugin in KDE or contributed upstream to Qt. Both of those are actually should be possible and if there's hindrances in the way, we can see what we can do to enable that. Sean is also talking, I think later on here here and ask him, I think he knows more, meant much more about the system than I do. Okay. There are some questions. I'm going to combine three questions about modules which are not in the list. People are asking especially about Qt Speech, Qt Location and about Qt GamePad, if there are plans for those three. Yes. So Qt GamePad, let's start with that one, is basically, I think it's, we just haven't published it, it does compile against Qt 6. So if you pull the code from Git, from code reviewer from Garrett, it just, as far as I know, it works against Qt 6. Not currently supported, we're not quite sure what to do about the module in the longer term, but it is there, the code is there and it should work. Qt Location is something that will come after 6.2 and we will be working on bringing that back. And then Qt Speech has always been a difficult module for us as well. Thanks to Speech and then Speech Recognition, we were never really happy with it. So we're not quite sure yet what we do, what we're going to do about it, but any feedback in that area would certainly be welcome. What people need, I would really like to hear what people want from the module, what they need. Okay. I have another Qt Quick Controls question, but let's try it anyway. Maybe it will be for the next speakers, but what do you define as native look and feel for Qt Quick Controls on Linux? Currently we're using Fusion there. And the question is, what is the native look and feel? Because KDE has been using the Qt Styling mechanism to define its own things. GNOME has been doing something else. It has always been a little bit of a mess and that makes it somewhat difficult. But as I said, I think Sean might also be able to answer a bit better there, what we can or can't do. So be ready for the next talk, people. So, okay, the next question is on the graphics side. So Windows also support Vulkan and sometimes you get better performance by choosing one or the other. I guess DirectX is the other. Can you somehow manually choose which graphics API is being used for a certain platform? Yes, there's an environment variable you can set to choose the platform. So you can do that just by setting an environment variable and it will use the one that you want. Of course, you'll have to be a bit careful if you yourself use certain graphics APIs directly. Then you have to make sure that those match, but other than that, just do it. We have another short but technical question. So why Q-Sites type instead of size T? Because we've had a long discussion around that one and the problem is that we've always used signed integers for indices in all our containers, also partially because sometimes you could use negative indices to indicate that you're coming from the end. Now, size itself of a container can only be positive, I agree, but those indices should be the same type. So we had to choose a signed integer to keep compatibility. It would have broken, using a unsigned version would have broken a lot of existing code out there, much, much more than we would have been able to, than we wanted to. The second argument was a bit that also many people in the C++ community think that signed is actually the better type or would be the better type for doing those things. It just causes less trouble in many other areas. Okay, and I guess the final question we're really almost out of time. It's the Qt Gamepad that I was asking before. There is a really, the question is a bit more detailed. It's a bit more specialized than that. So the question is really, if Qt Gamepad support is done, any plan for managing Gamepad events in the future? As said, we'll have to see what we do with Qt Gamepad first and how to handle that. There's certainly some work ongoing also because we are looking into areas like, even though with Qt Quick 3D, how can we extend that with VR support and those kind of things. And then those kind of game controllers fall in a bit more naturally also in terms of how things that you might wanna use to control your user interface then. So we'll have to see but that's work that's ongoing. I'm not sure exactly what the plans are but there's probably after 6.3 something to look into. Okay, I don't see any other question and in fact the time is almost basically running out. So Lars, thanks a lot for this presentation. Thanks a lot for all the work going for Qt in Qt and we will hear again about Qt in the next talks but thanks again. So a bit round of virtual applause. Unfortunately, the only virtual at this point. Well, thank you very much for listening everybody and have a good remaining couple of hours of academy and a nice weekend everybody.