 Yes, thanks, Lydia and good morning everybody. It's actually good to be here again At Academy Giving a talk this time. That's actually fun and I'm not getting it up on the screen What before before when I tried it? Oh, they replugged the thing No idea what guys what did you do? Okay, I'll let somebody else fix that and Start just talking a little bit It's actually a pleasure to be here as some of you might know actually I started working on cute and things in KDE a bit more than 20 years ago. I was a long time was Something that I did there during my studies as maybe many of you did when and gets when they got started and I got fascinated with the technology. I really started loving cute and I had The great opportunity to be offered a job there at that time trawl tech in Norway When they're started working on the technology Still doing KDE works in the early years lots of work on KTML But focused and more and more and cute now, so I'm doing to today I Think there's a signal going out by the way, otherwise I would have the screen would probably look different on my side Well, I'll let you to that Somewhat difficulties in any case So I thought I'll talk a little bit about Cute six today, and it's actually great to be here and cute and Katie. We've always had a pretty close relationship Cute as a technology would probably not exist today anymore without The help or the visibility that it got from KDE especially in the early years At the same time Katie is built on top of cute as the technology as the as one of the main frameworks and and where you all do build software on top of that as Has become a little bit of a thing, you know every once in a while. We tried to move to a next merger version of cute It's been Seven years now since we moved to Qt 5 And we're seeing now that hey fantastic Thank you so much So it's been seven years since we moved to Qt 5 and we've seen that a lot of things have changed in the world around us we have gathered a lot of ideas and things that we wanted to change in cute and fix in cute and So I thought and many other thoughts. It's about time that we move to the next major version of cute and Traditionally as I also know from KDE side This has always been a point where also KDE sat down then and so we thought of a couple of things and usually also moved to the next version of KDE Maybe a year or two later, but it usually happened With that so let's see what happens this time I'll going to present you a little bit the plans that we have for cute six some of the ideas we're having I have a lot of content Let's go through that maybe gal have most questions at the end I'm also here for today and tomorrow. So if you have any more questions afterwards Grab me and I'll hope we can go through some of those things Let's get started. I talked a little bit about that already the motivation We released Qt 5 in 2012 Was done somewhat in a haste after we got out of Nokia at that time that I don't know all of you might not know the history But Qt was owned by Nokia was used for their frameworks and at some point Nokia moved over to Windows phone and then decided to sell off Qt again and Everybody thought Qt was sort of a dead technology and we were trying to show people that it's still alive and we're really doing good stuff there Used the early Qt 5 years To prove that Qt was a viable technology Expand to the mobile and embedded ecosystems and largely expand our functionality as well Was a lot of stuff we did at that time But now after seven years, I believe it's time to adapt to some of those things that have changed in the world around us Clean up and we architecture our core as I said We've been doing a lot of focusing a lot on Expanding the scope of Qt in the early years Let's get back to the center and the core of Qt and see what we want to do and do then what we can't change and improve there and prepare what for what we See coming in the next years Give you an idea of what we're currently thinking of as a roadmap We have released 513 in May Currently working towards 514 we've gone gone and done Feature freeze and the branching for 514 just two weeks ago and Will work on that one Then we will have one more release Qt 550 next year in May probably with not a smaller feature delta from 514 to 515 than Usually even though there's still quite a few good things coming and I'll talk about one or two also here in this talk And then November next year tentatively Qt 6. Let's see how the schedule will change But I hope that we can some somewhat keep that schedule To do that. We've also started now moving most The development branch of Qt over to be Qt 6 and that's work. That's currently just happening Hope will be done with that in a week or two by two But before we go and look into some of the features suffer and things what's actually You know core and central to Qt. What are the things that you know, we need to take care of when we move to the next major version The core values that what makes Qt valuable for our users and our customers It's actually a couple of things one of them. It's cross-platform capabilities it exists on all age desktop operating systems on the mobile operating systems and we have a large coverage in on the in the embedded space as well Scalability you can do very small things with Qt people do huge Projects if you look out there on the desktop space things like Autodesk Maya KD, of course Air traffic control systems in Europe and Germany and other stuff We have we're trying to have really good API is great tools and documentation focus on that Or I forgot the ease of use. That's really really important C++ as an API tends to be complex We want to make it easy to use and have a good and intuitive API around all of the things we're doing Make it fun to work also with with Qt Should be you know the code you're writing using Qt should be made easily maintainable We should have stability in our API is incompatibility And of course we have a large developer ecosystem You know looking at our download numbers we expect we Estimate that there are around one million developers out there worldwide maybe a bit more than that using Qt regularly So a new version of Qt needs to adjust the product to whatever we think we need in the future While keeping those five six things at the heart of what we're doing Keep that always in mind with all the things we're doing For Qt 6 one of the things that we have realized that is the growth in usage for Qt will mostly come from the embedded Sector from embedded device. That's where we see a lot of companies now out there moving to using embedded Linux For example other some other operating systems like QNX, but they all want to attach a touch screen now to the embedded device We need to be able to scale down to rather low end hardware Because the price point in many of those devices is very crucial, but also scale up to high-end projects Desktop and mobile of course have a lot of the developer mind share and a great support there is a prerequisite for a Fast and Qt to be able to also grow into the embedded space and support all of that We one of the goals that I see is that we want to have an integrate more integrated workflow for everybody Includes not only the people that write code, but also other people that are associated With creating applications or embedded devices UX designers Qa engineers, maybe even technical writers. See how can we integrate those better into the workflow? We've started a lot of work there especially on the UX design thing because that was where we saw the biggest problem so far and Of course, you know How can we strengthen the ecosystem around Qt capture new developers provide a good infrastructure so that people can see that? I'll come back to that a little bit at the end of the talk It's not directly related to Qt 6.0, but Still something to keep in mind Then there's a couple of things that we want to do really for this First version of Qt 6 because that is the one place where we can break binary compatibility with Qt 5 and to some extent we also Okay, was breaking some level of source compatibility, so that certain things That worked in Qt 5 will not compile in Qt 6 anymore and Use that the opportunity there to prepare Qt for what's coming in 2020 and beyond a lot of cleanups in our code base to keep things maintainable for ourselves and and Hopefully be able to move faster and do all the architectural changes We couldn't do without breaking one of the two things above So that's really the goal for Qt 6. It's not about maximizing the amount of new features that we're doing it's about changing internals in Qt and Preparing for what us afterwards being able to do lots of new things Doesn't mean we will not have lots of cool new things in Qt 6.0, but The main goal has to be on that those three architecture rings So here's a couple of focus areas. I'll go through those afterwards and so just so you see there's a couple of things compatibility cleaning ups build system API Graphics, there's a lot of things around QML out to actually talk quite a bit there and the tooling side of things Compatibility with Qt 5 is important. You have a large code base in KDE Based on Qt 5 and some of you have been going through the exercises of porting You know from one Qt version to another from Qt 2 to Qt 3 to Qt 4 to Qt 5 and You know some of those efforts have been more painful than others Especially I would say 3 to 4 has been rather painful With 5 to 6 we hopefully we can do it in a way that it's not too painful for you I Want to keep the porting effort minimal as minimal as we can So we break the binary compatibility, so you don't need to recompile, but that's not not a big deal and Limit the source incompatible changes as much as we can even though there will be some things that we probably Probably say, okay, it's worth breaking this Because you know the gain is much bigger than the cost But limit those because each change that breaks source compatibility will require effort from you to port over and from all our users Avoid behavioral changes Because those are really really hard to find find unless we can detect things that compile time Now my goal is that we can have applications compiled against both the last last version of Qt 5 5 15 and 6.0 with let's say minimal work arounds Let's see how close we get to that goal, but we should have that as a goal in mind Nevertheless, we'll do some house cleaning and we'll remove all functionality that has been deprecated in the lifetime of Qt 5 I Don't know if KD has turned on deprecation warnings. I hope so Because then it's easy If not, it's a bit more work That's a problem, but yes, so We'll remove all of that functions in module for all modules some classes and and you know Individual methods inside classes modules that what we'll get removed just so you know already Qt script old JavaScript engine Qt canvas 3d Qt quick controls one Qt quick one. I don't know it. I hope no you're not really using a whole lot of that anymore, but let's see Some classes will probably get that get removed might end up to live in a Qt 5.0 Compat module with I'm not sure about that one yet It depends on how much they're going to be used but Q reg X and Q list could be a could be examples of that I'll come back to Q list a little later and tell you about about the plan there But reg X we have Q regular expression I really want to remove the amount of JavaScript engines regular expression engines Because currently we have three of them Feels like too too much So let's get at least rid of one of them good Another thing we're doing and changing is the bill system that we're using for to build Qt. I I thought you know at least here in this audience. This would be uncontroversial great It's not quite as uncontroversial some other places, but I think it's the right choice We will We've had Q make for a long time. It was done during Qt two years. We will still support users Using Q make in Qt six. So that's not going away We will have to support Q make the amount of users out there just too big But we encourage now a new people to start their projects using CMake as the build system And that's what we're going to use for Qt six ourselves as well. There's a good effort on going We have a had a couple of workshops there part of them in in the KDAP offices in Berlin We're making very good progress. I think and I hope that we can merge that into the development branch within the next Month or two, hopefully So that's I hope good news Another thing we're going to do change is that we're upgrading doing the C++ version that we require to you for Qt 6 move over all the way to C++ 17 can't move to 20 yet because the compilers don't fully support it especially there's lots of problems with Apple clang and Microsoft compilers But we want to use C++ 17 For to build Qt as a minimum requirement and we want to see also how we can integrate better with some of those See standard API's That's just balance. We need to strike here because the standard API's Have somewhat different goals and Qt. They want to they have a You know their goal is really to to make them allow for most efficient implementations Don't pay for what you don't use Cute the goal is slightly different. I want to have API's that are easy to use and easy to maintain So for me, it's more important that it's easy for developers to get to their goal Implementing things and maybe you know if you pay a few extra cycles there. It's probably okay so intuitive and simple API's Something really important for us and we want to continue doing that Make C++ easy and accessible some of those standard API's can get very intimidating for people coming to C++ from other programming languages If it's template heavy, I mean all of us I know struggles still from time to time and then you go back after a couple of weeks and we read your code that you've written and Takes you a little time to understand again what you've been doing there. At least that's for me So I want to make sure that the API's in Qt stay easy and accessible and It's fine because 90% of the users code is usually not performance critical So some extra cycles for simple simple API so to make keep API simple is probably acceptable But of course not acceptable if things work go from a linear Algorithm to a quadratic algorithm or something like that or log n to to quadratic So ideally want to have both simple API's great performance see how we can do that We've been good at that in the past when we now want to work closer with C++ 17 There's certainly some place where we need to find out where the compromise is between those two things Unicode throughout that was a goal. I had already put out for Qt 5 and we didn't manage to pull it through completely Reason was that There were a couple of Microsoft compilers didn't really allow us to that do that because I wanted to basically say okay Let's by default Interpret all source code as being UTF-8 Clang and GCC and already do that By default, so that's good all text handling assumes Unicode all conversions from Basically a literal string in source code to queue string assume UTF-8 We want to move all the codec related things for you know different, you know text encodings Latin one shift Is whatever out of Qt core Separate library if you need it, but let's not have that integrated in Qt core anymore One thing that came up lately and that's been a little bit more in the thinking and this is still early thinking for me But I would like to simplify our string handling with it's got two complex. I remember You know in 2002 2003 I was at Academy there and we've been looking at Mozilla source code At that point and we started making fun of it because they had 20 different string classes or seven something nice, I think it was a more seven and Let me see Q string literal Q Latin one string const cast stars Q string Q string ref Q string view Did I miss something at least that six? I think I missed something By the way with you know a Latin one encoding We're getting just as messy. It's getting too complex. I we need to simplify that I have still don't quite know how to do it, but I have some ideas I would like to have something where string literals can just be written in quotes Whether you use a you prefix or not in C++ 17. I don't think that should matter Q string Q string view make by the way probably ask you only and hopefully we can duplicate all the other ones and Then the question is still for me also a little bit Can Q string actually support both utf 8 and utf 16 behind the scenes? There's a couple of methods that expose the internals Makes it a bit tricky. Let's see something to think about at least I want to think about what can be done there Wanna rethink our containers a little bit Unify Q list and Q vector Q list has been this little bit complex class you know with different behaviors depending on different types and different attributes or Type infos you think how you declare type of info Basically kill is if kill is becomes an alliance to vector Q vector. That's almost hundred percent source compatible It simplifies our API because we have one less container class to worry about and It improves the performance in pretty much 90% of the cases So we're good with that. I want to do that and I have the patches there We just need to work out a few final details The question is back. Can we base Q map Q set Q hash our associates give containers on the standard API's for better interoperability And actually to reduce our own maintenance load on those classes But it said it's important that we keep an easy to use API there There's something to think about in the core of cute. There's other things that Items that were were going through But can't probably mention everything here and I'm running late anyway already so Have to see a big Topic for me is also looking at QML in the next generation QML What can we do there QML was we released that as a first version in Qt 4 8 and then kept the language pretty much Unchanged for Qt 5 even though it could quick the UI elements changed quite a bit QML currently has some issues We require full JavaScript engine and the garbage collector, which is not very suited for low end devices and hardware and needs can lead to some Unpredictable performance characteristics due to the GC The object model is built, you know on top of the Qt object model So meaning it's it duplicates a lot of data structures at one time We have lots of mallocs and a large initialization overhead Things like binding propagations in QML the immediate and they're not really synced with a scene graph and we're duplicating a lot of binding evaluations there often and We have a weekly type language which has its own share of problems because we can't easily Generate most the most efficient code at compile time. We can only do that at one time using a jit which was not ideal and It also has problems in terms of refactoring code We have a language problem some of the scoping rules in QML are difficult to understand, you know, what's in scope and where The integration with C++ is not quite ideal Sometimes you've been probably doing that. It's it's doable, but you know, I wish it was simpler And the QML versioning has been a pain as thrown in my eye for ever since we had it Because it's in its C++ doesn't need that right We do minor version upgrades in C++ without having to do any versioning of that stuff Can't we do that in QML? And I think we can with a slight change to the language And it would make our life easier to maintain Cute and it would make the user's life easier maintaining their code we don't have private properties and I said the weekly typed Being weekly type means that we can't catch things that compile time coding errors, which I think is an is problematic And we can't really see also all the types in the code models So changing a lot of things for Qt 6 we want I want to introduce strong typing there make that available At least optional JavaScript should be optional as a feature in QML Get rid of the versioning Get rid of the duplicated data structures don't generate a lot of data structures at runtime even if we can avoid it If you can compile do them at compile time Support compiling QML to efficient C++ native code. We've had a QML compiler that compile in You know as a commercial thing a couple of versions back that compiled QML to C++, but it wasn't efficient It was still generic code Hiding implementation details and better tooling Let's see what we're doing there. First thing is Improving the type system we want to generate better type information at compile time Requires some changes to Qmeta type and how we register that data Certain thing features and certain data to the meta object system that we require in QML So that we can also, you know put that into the meta object and meta data at compile time and Make sure that we can look up that data fast enough because currently Those meta type lookups are not really efficient. They may not made to be as fast as possible And with that I think we can get rid of the QML property cache runtime data structures We're also looking at that's going to be an exciting thing from the C++ site as well as a completely new property system First time I mentioned we're mentioning that in a lot also a bit more in public I Want to have a we want I want to have a real property based syntax So no pseudo properties with foo and reset foo But you just have a property on your object and you can assign to it and you can read from it We have a prototype actually working it's looking pretty damn good It has we want to have built-in support for bindings So you can do bindings also on the C++ site and move all of that all the way down into the core of Qt into Qt core Make it available for all of Qt and use it everywhere so also in widgets Haven't really easy to use C++ API and actually it removes a lot of glue code There as well if in many cases where you'd have to connect to a change signal and then do something Can do that much easier now Will support lazy binding evaluation so the binding will only get re-evaluated when you read the property and It will mean a significant reduction memory allocations for QML and it's actually a lot faster Here's the syntax For if you basically creates your own class You can put in properties for example It's in width height and then you can set up bindings so you can bind the height to the width. It's always square The item and you can set a border and bind that to a tenth of the width so you have a tenth of the width is always the border and We have tested that we know this works. We have this implemented and You can basically read the width and and assign to the width just as you ever wanted to We'll take care. We'll make sure the dependency stay in sync when you sign to the width the bindings For height and border will get marked as dirty and when you read height and border the bindings will get re-evaluated We'll make sure that you get the right value out We'll compile QML to native code I already talked about that and with the full type information that that we hopefully then have in the new version of QML We can generate really efficient C++ compile into C++ classes QML properties will mark map to that Q property instance that I just showed and QML bindings can be mapped to C++ bindings Con Qt QML will be we are thinking about splitting up Make it a way actually a relatively small runtime for QMPile QML Move the object model into Qt core lots of other things into their own libraries, especially also the JavaScript part As said separate JavaScript Qt QML should not depend on it and so these are Qt quick and others those should be should be optional and With that we have a slightly restricted QML that we can compile to C++ and JavaScript you will still need for certain things if you want to include new JavaScript in your project Or if you want to use items like canvas or worker script and these kind of things But without we can remove this hopefully we move all Qt script dependents JavaScript dependences from Qt quick and then we finally you know to fill up the gap that Qt script leave Getting rid of Qt script leaves. We need to extend the QJS type of APIs a little bit there on the language changes We'll need to remove context properties to be able to do that. You'll need to use singletons instead Some some would simplify the lookup and scoping rules, which means that you need to explicitly use the ID in a few more places But well then we can also remove the QML versioning make that unnecessary have the strongly tied support available as I said and Compile all of that down and add may hopefully private and public as qualifiers for properties and functions Compatibility we'll need to differentiate between Current QML and the next QML. Maybe with a file extension program or import. We don't quite know yet With QML 2 we'll need to do things at one time and still interpret or jit The QML code so this will it will probably stay relatively similar to what we currently have there But we hope that they can then use still the same Qt quick library on top of it So with that we're moving a lot of work from one time to compile time should be a lot faster with binding evaluations I did some initial benchmarks and it's 10 to 100 times faster The binding engines, so it's a really big improvement that we can get with that The reduction in memory consumption should also be very significant. We've done some work there with I Don't know if you've seen our announcement around Qt for microcontrollers, which is basically actually just Qt quick a Reimplementation of Qt quick fully from ground up to microcontrollers Using a lot of the concepts that I've actually presented here now, so we're bringing all of that work now back into Qt 6 and We can run there with half a meg of memory a UI a fully fledged UI It's pretty good So so that's what we're doing on the QML side. This will be a large project and require quite a bit of work, but I'm pretty confident we can do at least most of it We're working a lot on the on a new graphics architecture and actually you might have seen some of those things already Some of them are coming already to Qt 5, but Qt 6 is where things will come fully come together the architecture Goes into looking also at the bottom that we have now more than one graphics API OpenGL is not the only player in town anymore as it was when we released Qt 5 There's Vulkan, there's Metal, Apple has deprecated OpenGL There's Direct3D on Windows. We want to make sure we can support all of those And we want to make sure that Qt quick as a 2D UI technology gets proper and easy to use 3D extensions for the Graphics independence we've now introduced what we call the Qt rendering hardware interface It's basically a very thin abstraction layer on top of the graphics APIs and It's tuned towards the need of Qt itself currently. It's also private API and Qt builds on top of the Qt platform abstraction API where we support now OpenGL Vulkan Direct3D and Metal Parallel to that we have the shader tools which is helping us to write to create a shader actually if you write an OpenGL shader Or it wouldn't work on Direct3D So we need to have something to cross compile those shaders from the one language to another We do that with the shader tools package which builds on top of the spear v ecosystem toolchain by Kronos Without you can create a fully cross Shader package that then works everywhere on the higher level as said we want to introduce better 3D support for Qt quick Currently what you have is that you have Qt quick and the some 3D whether that's Qt 3D or the Qt 3D studio runtime They're side-by-side independent scene graphs independent run times they're doing their own animations You can't sync between them And it's actually has a lot of overhead especially on low-end hardware because one of the two needs to be rendered into an off-screen frame buffer So bring those together Qt quick and extend that with 3D capabilities Well, you have one street scene graph and it's all based on top of QML And way you have one animation system one state transition system So it's just an extension to Qt quick in the end Here's an example. I'm not sure or you can read that from the back But this is how Qt quick 3D now looks builds on QML has all the language features available As I said, you can use it with all existing Qt quick APIs. It's just another import It has a high-level API for 3D content if you see here This is an example where we have a 2D Qt quick image element and the 3D cube in there You just create a window You have the 2D image element on the top and we have a view 3D which is you know says about the 3D view where you have an environment a Camera and then the model which is just a cube with a glass material and then the there's a rotation animation there That rotates that cube. It's very simple and straightforward and even you know for most people who don't really know the in-depth OpenGL it's very easy to use and read and that's that's really the goal for us For both of those technologies we have we're trying to get at least part of that into Qt 5 already 514 as a technology preview and then 515 supporting both the rendering hardware interface and Qt quick 3D There's one limitation you Combining Qt quick 3D and the rendering hardware interface will not work in Qt 515. You have to choose one or the other That's Qt 6 material then that's where we bring everything together And we clean out also all of the direct OpenGL dependencies we have in Qt In Qt 5 we currently having two graphical tools to create user interfaces with Qt design studio Qt 3D studio design studio just being a Qt creator with a different user interface on top. That's designer friendly The separate independent applications and we want to basically bring those together and align all our graphical tooling on top of Qt creator So design studio is Qt creator with a designer-centric user interface and Merge all the 3D design functionality that we have back into Qt creator and design studio So we have one set of tools that help both the designers UX designers and the developers UX designers also have all the development functionality behind hidden they are hidden behind the scenes so they can go and basically Hidden without them really seeing it compile for an embedded device and deploy to that device test on that device So this is a bit of an overview over the technical work There's a lot of other smaller things throughout Qt that people that we're planning on changing Probably don't have time to go through that. I have a little bit of a final thing on You know the product structure and what we're doing there and This will also be the one place where I mentioned a little bit of our the commercial side of Qt as you know it's dual licensed and Qt development is funded Pretty much by the people who buy a commercial licenses at least that's you know, even though we're working as in the open as an open source project Qt companies taking the 90% of the R&D costs and We have a very large product So all of Qt for application development is open so free free software Most of Qt device creation is actually also free software, but the package Thing is something that we only have available commercially So Somehow we need to find ways to balance things so that we can grow the business For the to be able to fund our future development as well as growing the ecosystem by having the free open source version available there From that perspective, you know the current licensing is not hundred percent ideal Ideally would be something where we have a bit more GPL content on the add-on side Keep the essentials LGPL and then maybe some commercial licensing for integrations with commercial stuff Where open source makes a lot less sense We'll see how this develops and and what we do there. This is also something which we're talking currently with The KDE free Qt foundation about let's see what this leads us Still a very much of an open discussion But one thing we want to do is with Qt 6 is we want to go for a little bit of a smaller set of core libraries and the product Have the core product the Qt packages that you download a little bit slimmer mostly the essentials and the tooling Just to also simplify our work on getting releases out and deliver add-ons a little bit separately There's also a need for that for example very strongly in the web with web engine Which we has a would actually need an update schedule That's much much more frequent than what we can do with Qt chromium is updating every six weeks We have releases every half a year and then there's the LTS releases Which would need for security updates also in your chromium version So decoupling those release schedules would be actually makes things much easier in that respect And the way we want to do that is by introducing also marketplace as a central rallying point for the Qt ecosystem And there we want to give everybody the opportunity and the place to publish their own additions to Qt That's of course also something that's an opportunity for you here to think about Whether you want to do that want to have space for both free and paid content and make it easy to discover Additional functionality Qt and it also comes from the realization that we can't put everything into Qt itself There's things that are around in the ecosystem and we're seeing that others have been You know introducing those kind of marketplaces and and and getting a lot of really good feedback there so The idea is that the content on that marketplaces mainly focusing around extensions to Qt to the tools to the frameworks content that integrates with Qt Maybe graphics or assets new a new style for for for Qt widgets Qt quick controls imagery Maybe you know in the longer term AI models that you can just use and plug in to do image recognition something like that I don't know what it will be But I hope we'll get a lot of good and interesting things there And then we thought about delivering some of our add-ons just simply the same way through the our marketplace and by that decoupling the release schedules So this is a little bit to the side of Qt 6. It's work. That's already happening now a bit in the Qt company We hope to have something out there by let's say World Summit approximately at least as a first proof of concept initial version minimum viable product something like that So lots of things happening. I think I went a little bit over time. I hope that's fine and You'll forgive me for that one. Thank you very much for listening