 I'm honored to be here. Thanks for the opportunity. Myself and Pedro down here want to share a bit about our thoughts regarding how we want to build the future of Qt and how we want to make you part of that. A couple of words to myself first. Volker Hilzheimer, I'm a stranger to most of you. I'm not a historical member of the KDE community. I have been with the Qt community for many years, not uninterrupted. Nevertheless, I have now been the chief maintainer of the Qt project since June, and this is my first appearance, my first public appearance at least in that role. And also, yeah, Alish mentioned it a couple of years with the pandemic and so forth. Thank you, thank you. So it's also the first time in many years that I'm speaking in front of a room of strangers. And thanks to the organizers of last night's wonderful event. Not all of you are strangers to me anymore at least, so that's good. And also thanks to Paul, for instance, for the interview leading up to this, talking to both me and Pedro. So I hope you have a bit of an idea of who I am. The chief maintainer of the Qt project is to a large degree a coordinating role talking to all the different maintainers that we have for the different modules and different parts and components. I believe some of you are here already, and hopefully others are listening online. But it's also a responsibility to bring the vision together and to communicate the direction of the Qt project. And that's what I'm trying to do today. So the idea is what are the hot topics that I'm at least thinking about and that I have been talking about to some of the maintainers in the past couple of weeks and months since I took over from last. What are the hot topics for the future of Qt? It's not a roadmap presentation. We released Qt 6.4 just recently on Thursday. And yes, now we are developing, of course, Qt 6.5. The wheel is turning. This is not a presentation about what we are going to do for 6.5. But I'm trying to rather look a little bit above that horizon and think about what is happening in the industry, what is impacting us as a project, and how is that relevant for you in the KDE community? It's been almost two years now since Qt 6 has been released. We are soon bringing back the last significant missing module at least with Qt location, for instance. I know that adaptation of Qt 6 takes time and that you are also working on that particular journey. I would be interested to know a bit more about that in the next couple of days. I'm here until Tuesday to find out where you are, what your challenges are. We are now seeing that the Linux distributions are starting to pick up Qt 6 and that we have, for instance, worked with the Debian community in particular to get Qt 6 there into the repositories, which is great. But yeah, the adaptation takes time. Nevertheless, there are things, of course, that we are thinking about already beyond of where we are. Let's go through a couple of topics that, again, I have been thinking about and that I believe are quite interesting given where we are right now. One of the things we very recently released now on Thursday, official support for WebAssembly. WebAssembly, I think, is an extremely exciting technology for us as an industry for those of us who build applications. It has a huge potential, I believe, to be quite a game changer to how we do things. In the context of Qt, Web and Qt and Qt and Web has always a bit of a discussion of, is this, are these competitors? And yes, of course, web technology, developing applications and user experiences with web technology has always been a competition to building native applications with Qt. But Qt has always been web-friendly, or at least for a very long time. Alan is sitting over there, for instance, leading all the work that we are doing in the Qt company with regards to Web Engine and Chromium. So having web content in your Qt application is nothing particularly new. And also historically, I don't know if many of you remember it, but we used to have, for instance, Netscape plug-in frameworks in Qt from the very early days and things like ActiveQt to embed Qt content in the web page. Now with WebAssembly, this is taking a whole new level. And I think Qt in the web is going to be a very exciting, very exciting future for many reasons. One of them being that it's near-native performance. You can bring a native application to people that are consuming their user interfaces and their user experiences in the web browser or in at least a web runtime to people. It's zero deploy. That is something that our customers in many cases care a lot about. How can we bring our application to our users and how can we make sure that that application is always up to date? Not limited also in terms of user interface development to what the application can do by, for instance, what HTML allows you to do. People in the industry talk today about if we had had WebAssembly in 2008, we wouldn't have needed Docker. And if you follow, for instance, the conversations that are happening in the serverless space, uploading your code to a hosting provider to run your stuff with very low latency, very lightweight. WebAssembly opens completely new opportunities there. Technologies like Isolate and V8 or Micro VMs and so forth. All of these have their pros and cons. And WebAssembly is bringing a lot of promise together in terms of how lightweight it is, how secure it is, and how performant it is. And security is very an important part of that, very much so because, yeah, we have experience how coexistence of different computing routines, for instance, on the same device and the same host, even within the same process are, of course, providing a huge attack surface. And WebAssembly is designed at least to tackle many of these things. And again, from acute perspective, that is, or from an application developer perspective, this is very exciting in that sense that, yeah, you can, for instance, bring new content into your own application as well. Maybe that is a future we can think about. Does WebAssembly allow us to build applications that can consume more content dynamically load stuff, have an ecosystem built around user experiences that are all based on WebAssembly as a technology? So I think there is a lot of interesting stuff happening there, and there's also lots of research happening there, for instance, especially in the website or in the web experience, how does acute application in a web front end, in a web UI integrate? How do we make that a consistent user experience? How do we do things like status handling, stateful handling of sessions? How do we share URLs? The things that people are used to from using web applications, if the web application embeds acute WebAssembly, how do we make that state serializable across URLs, for instance? And of course, WebAssembly being a standardized binary format makes it also very exciting in terms of language integration and collaboration. Many languages can be compiled down to WebAssembly bytecode, and if they can all coexist, that is a whole lot of new opportunity. So yes, WebAssembly is now something we have been investing a lot of time in in the acute company building and now releasing it or having released it in 6.4, and I'm quite excited of what can happen there still in the future. I don't know how you have thought about WebAssembly as something that's relevant for KDE, for the desktop experience anyway, for end users. Let's talk about that. Yeah, languages, upper-poor computer programming languages. I think there is also there a lot of stuff happening in the last couple of years. Of course, C++20 is, for us right now, very topical. Lots of work is happening to make acute compile and, to some degree, prepare it for acute to also use C++20 language constructs. C++ is still a fantastic language. The secret power of C++ is really creating instructions, and for us as library developers, that is an extremely important tool. In future, we have always tried to make C++ accessible and easy to use, and what is now in C++20, the big four features, ranges, concepts, modules, and coroutines, we haven't really started to use those yet. And I think that is one of the things that we are spending a lot of time thinking about and also preparing the door space for C++20, Mark and Peppa, for instance, spending a lot of energy on making things work there. And then of course, yeah, QML, our language in Q to build user interfaces. There is still so much opportunity there. One of my favorite quotes is from Patricia Oz, who is building a web browser using QML for the Chrome for the UI, and she's saying, imagine if Jason JavaScript and CSS had a love child. And that's how she describes QML. And I think that's a very good way of thinking about it. It's a great way to build UIs. It's a great way to build UIs that can be easily changed. That is one of the main features, I think, of a good framework technology to result in code that can be easily evolved and easily modified. And yeah, in QML, there is still lots of opportunity. We are doing a lot of work these days in terms of value types, for instance, if you are following what Ulf and Fabian and the team are doing, I think there is lots of stuff that is going to make it easier to bring C++ into QML and to generally make QML more expressive, make it easier to write. Not everything that we had in mind for Qt 6 has been done in that respect, so there's still a journey ahead of us. Also performance, of course, the compiler tool, two trends that we are working on. So on the QML side, I think there is still lots of stuff happening. And then there are lots of other languages, ultimately, if we are speaking about C++. C++ 23, of course, is happening these days. But many interesting features there, perhaps not quite as significant as what we have seen in C++ 20, but just like a stack tracing library in C++ 23. That's going to be an extremely valuable tool for us as software engineers and software developers working in C++. If const and eval ranges implementations and improvements and so forth. So C++ 23, of course, interesting. And now it's year 2022 and people have joked that 2022 seems to be the year of the C++ successor language. So there are lots of things happening there as well. Google has recently published information or a carbon project, for instance, which they consider to be an opportunity for a candidate for being the C++ successor. And also Herb Sata has talked about CPP front as a front end to C++ that basically gets the defaults right, which I think is a very good idea. Any of these initiatives that make it easier for us to write high-performance good software that is also secure, that is also free of memory leaks and so forth. I think these are great initiatives. And we, as the Qt project, really need to and want to be able to see what of that is relevant for us. What does that mean? Python is, of course, something that we have invested in. Qt for Python has brought Qt to a lot and a lot of people that would have never heard or thought about Qt in the first place. So in terms of just bringing Qt out there and making that available and making people aware that it exists, Python has been a great language for that, bringing the simplicity of Qt to it. And, yeah, of course, people are asking, what about Rust? Are we doing anything there? We are not doing anything actively there. But again, it's one of these things that we need to look into. How does Rust impact our industry? How does system engineering change? How does system development change? So for us as a Qt project, I think looking at Qt is not necessarily as a C++ framework. Because that limits so much of who feels that it's for them. But rather saying, there are so many programming languages out there, many of them don't have a user interface framework because it's bloody hard to build a user interface framework, especially one that's cross-platform. Can we make all the good stuff that we have done in Qt available to those communities as well? Like what we have done now with Python, modern C++, QML. But, yeah. Circling back a bit, again, WebAssembly, a common runtime, language independent, things can be compiled down to WebAssembly as well. So again, here is an opportunity for us to really think about how do we make this work together. User interface, I mentioned none of these languages come with the user interface standard library. And many people think about Qt as a user interface framework. And of course, that is where we come from. And that is still a significant part of what we are working on. It's not the only thing that we are doing. But the user interface, of course, is a big part of what we care about. So yeah, controls. What is missing in Qt? Where do we want to go with the control library and feature set that we have today in Qt? And what's missing? What's missing in terms of desktop user interfaces? What are you missing in Qt? What are you missing in Qt quick? Qt widgets, of course, is not something we are going to actively throw a lot of new functionality into. We want to make sure that it remains relevant and remains up to date also as the operating systems evolve and bring new user interfaces and new concepts into the into the place. But Qt quick is where we are seeing that we really have the right technology for future development of UI framework. So what is missing there? What is missing there in terms of framework capabilities, infrastructure, but also what's missing specifically in terms of controls that are available? We want to make sure that it's easy to build user interfaces with Qt and having ready made components is, of course, a big part of that. And these user interfaces should be good user interfaces and good user interfaces absolutely does mean accessible user interfaces, both in terms of the literal word accessible, usable, but also, of course, accessible in the sense of assistive technology, making sure that people of any kind can use the interfaces that we are building. Consistency is important there. How do we make sure that it looks correct, that it looks natural? How do we make it responsive? User interface development in Qt today. Responsiveness is not one of the first things you are thinking about in terms of layout responsiveness, I mean. Performance snappy, you click the button, you see it, of course, but having a user interface that is designed for different form factors for different orientations, or if we live, again, in a web browser with our UI, we have very little control over what the user interface real estate looks like ultimately. And people might download your web assembly to a browser on your mobile phone or to a browser on your desktop. So having the ability to build user interfaces that can be well functioning and well accessible in all of these contexts, I think there is still lots of research and lots of thinking that we need to do and then ultimately also, of course, building, building the building blocks, providing the building blocks. So responsiveness in terms of layout is one aspect, scalability is another aspect. How can we make user interface, if you are a user today of a browser application of a UI in your web browser, you are expecting it to be scalable, you're expecting control plus to increase the font size or to increase the entire user experience. This is also something that we want to think about. Can we make this something that every Qt application provides as a service, especially when it lives in the browser, it needs to be able to participate in that, in that interaction, but also, okay, why should the standalone application that is written with Qt not allow the user to zoom into certain aspects of the user interface without having their entire desktop zoomed in. So I think there is still, again, we need to make sure that Qt functions well and interacts well with the user no matter where the application ultimately lives. And then, of course, personalization. We have not spent as much time on making sure that Qt applications look great on the Linux desktop in the last couple of years. Let's be honest about that. We are now starting to look into this again, making sure that Qt applications observe and obey the theme, the colors that are being used by the user, making sure that we respect the user's choices on any desktop, also making it easier for the application to be aware of is the user running in light mode or in dark mode, are they using a high contrast theme? How can we make that information accessible to the application developer and also implicitly makes the right choices unless somebody explicitly wants to make some other choices, of course. But respecting the user's wishes and preferences is really important. And again, that's something I would like to talk to you about during this event now, also, what's missing in Qt in terms of infrastructure for you to build highly attractive and highly engaging user interfaces in KDE, but also, okay, what's missing in terms of personalization infrastructure, for instance. So user interface, lots of stuff happening there. Many of these things we are working on quite actively, especially, like I mentioned on the personalization aspect, seeming support, we are researching into responsive layouts and into scalable UIs. Accessibility is something that Qt has from the very early days on been looking into and trying to make sure that it works correctly, but that there's always work. And of course, yeah, building new controls. And then there is another aspect of user interface development that is really HMI development. I'm taking that as a different thing from UI development. UI development, if you think about, okay, you're sitting down, you're using an application, that is the application you're interacting with right now. HMI human machine interface is relevant in a very different context, because you don't use that device for the use of the device's sake. You're using this device in the context of doing something else, that machine that you're interacting with. And that's why I think HMI development has a couple of additional aspects to user interface development. Situational awareness is absolutely part of that. The user using your user interface is busy doing something else. And that something else might be critical, it might be dangerous, it might be driving a car, it might be operating heavy machinery or a medical device that has very different demands and expectations to what the user interface provides to that operator of the system. So situational awareness, making sure that the user is that the HMI gives the user tools to know what's going on around them. That is not the same problem that we are solving if we are writing a desktop application. Or even the mobile application. So design driven, understanding the domain, making the right trade-offs, making the right choices. Choices bringing the designers into the field to really understand what is the user doing, what is the domain that we need to understand in order to build a good human machine interface is an important part of that. I'm not saying that user interface development on the desktop or on the mobile side is not necessarily benefiting from a design driven approach or at least from inviting the designers to the party. But I think for HMI, it requires a lot more understanding. We can't just rely on, okay, this is what it looks like on Windows, we are probably not going to make a very bad job if we are following that paradigm. On HMI, it's a very different situation. So yeah, design driven user interface, using multiple channels as well to communicate information. There's a lot of stuff happening often. If you're driving a car in heavy traffic, there is a lot of stuff happening around you and just a screen that you look at, it's probably the worst thing to use to communicate information when you are driving a car because you don't want the driver to look at the screen. So we need to think about things like sound and speech using all the channels, all the senses to make it possible for the operator of the system to be situational aware. Animations, 3D, we are spending a lot of time on building 3D support into Qt with Qt Quick 3D and we are not doing that because we can or because it's fun, but because creating visuals that are relatable and that are again using all the dimensions, all the senses, giving the user all the opportunities to understand where things are in a relatable way. That is where 3D and where animations are an incredibly important user interface, the line tool, and making sure that these things look relatable. Doesn't mean that everything needs to be highly realistic, but at least giving the designers the tools that they need to make it easy for the end user ultimately to understand where things are, how things are moving, where they relate to you as an operator right now. So, yeah, designer experience is an absolutely important part of that again. This is not something you'd simply do by writing a lot of code, building a good effect, building a good 3D user interface or an animated user interface. You need the tools to be able to do that interactively and visually. You can't just, even with QML, even with highly functional languages for exactly that purpose, you need to give, we need to give the people that are building these interfaces, the tools to do so interactively. And that, of course, ultimately means that we want the designers and the developers to collaborate, and that's one of the strategies that we have as the Qt company, and I think also for us as the Qt project, that is really one of the key strategies. Make sure that designers are creating working code, not wireframes, not prototypes, not sketches that are then thrown over the fence to the developers to hopefully get it right, but rather work together on the same code base directly within the assets, directly within the software, make it easy for that to happen. And QML has been a success story in that respect. Design Studio has been a success story in that respect, but there is still lots of work that we want to do here. Okay, that's now been UI development, HMI development, but of course, like I mentioned, Qt is more than just a UI framework, even though that's perhaps what most people think about. Connectivity is also absolutely interesting for us, and Qt has had a networking library for ever, as far as most of us are concerned. Building software that talks to web services, consumes data from other places, hasn't been, has always been possible. But nevertheless, I think making connectivity part of the heart of Qt is still something we can do more with. People are mobile. People will want to create content on the road. They do that already, of course, and how do we make it easier for people to write applications that make that easy again? TCP sockets, maybe not the best of structural layer we have for that purpose. We have JSON APIs, we have HTTP protocol, but again, can we make it easier for application developers to communicate and to consume web services and to share data, things like authentication and so forth, all the infrastructure that we would like to have available as application developers. There is still work to be done here. The data lives on the edge where people are with their devices, be it mobile devices, be it embedded devices, that's where the data is, and we need to make that data then available for processing, for consuming, for doing something, but for becoming knowledge, for becoming information. We need to make that possible and easy for developers of devices, for developers of application. So one of the things we released, you might have seen in 6.4 now, is the first tech preview of an HTTP server that you can easily embed into your Qt application, especially exactly because of that. Where these applications run, often in embedded systems where data is living, where sensors are providing information or data at least, that's where we need to collect that data and then we need to make it available and serve it back. So these will be distributed experiences, distributed systems, again, that is not something today that you think about as a primary use case for Qt, building a distributed system is, yeah, there are many frameworks out there. Qt is maybe not on the top of the pile of candidates that you would use as technology, but especially when it becomes distributed also in terms of user experiences, that's when we need to really see from, look at this problem also from a user experience or user interface development perspective. Yeah, building services, multi-user experiences like I mentioned, collaboration ultimately. How do we make that possible? How do we make it easy for people to build applications that allow end users to collaborate? We are starting to get used to that ourselves from our IDEs, from how we develop software, not just in IDEs but also ultimately the web experience of that, the GitHub experience or GitLab experience of that, but even in the IDEs you might want to say, hey, let's collaborate, let's co-write that code even though we are not sitting next to each other, we have programming and so forth. And yeah, speaking then of collaboration, of course that is a segue for me to also talk about community and how important community is for us as the Qt project. Qt and the KDE community have a long history, a good history I think. Neither Qt would be what it is today nor perhaps would KDE be what it is today. It would happen being for the collaboration we are having. And yes, that we now have a community manager and the Qt company is great. It's evidence that we are starting to put also a bit more attention on that topic as the Qt company, but I think for the Qt project itself, it is incredibly important that we have a rich and active, a vibrant community and a diverse community. When we open sourced or rather open, put Qt under open governance in the Nokia days, it was because also users of Qt when Nokia acquired TrollTech were worried that now the entire roadmap of Qt is dominated by what Nokia needs. So one of the tools against that was to say, let's put it under an open government. Let's people and companies that have made the strategic choice to build their business on top of Qt-based applications on Qt-based software. Let's give them the tools to contribute and to participate in the setting of the direction of Qt. And that's definitely something I think is incredibly important today. The Qt company has a very interesting history and that we are still there is also because we have a very diverse customer portfolio. We are in 70 different industries and that gives us a lot of strength. And I think for the Qt project, it's equally important that many different people, many different interests come together to build Qt and to develop Qt further. Not everything that you want as the KDE community will be aligned with what the Qt company sets as a priority. Not everything our customers think we should focus on is what we are going to do for the next release. But having a community where we can have those conversations, where we can have those discussions and disagreements, I think is absolutely important and being actively participating in that community is helping us build a better technology and a more resilient technology in the long run. So diversity of interest. We have a lot of contributors today and we have a lot of contributions today. We are very biased always to think of contributions, a source code contributions, even there 25% roughly of those come from outside of the Qt company. I think it could always be more, but I think 25 is a quarter of all contributions going into Qt from outside of the Qt company. I think that's great. We have definitely more than three quarters of our contributions into JIRA into our bug tracking system come from outside of the Qt company. And honestly, almost 100% of the real world problems being solved with Qt are being solved outside of the Qt company. In the Qt company we are developing Qt, we are developing tools around Qt, but you are the ones building the real software, the software that end users are going to be using with Qt. And your perspective is incredibly important for us to make sure that what we are doing with Qt is making that easier and making that better. Also our maintainers, I mentioned them, a few of them are here. A third of, more than a third of our maintainers in the Qt project are outside of the Qt company. Creating that mind share is also one aspect of what makes Qt a successful and resilient in the lasting technology. It has been part of the success story so far. I really hope that it will also be part of the success story in the future. Like I mentioned with opening Qt for more languages in the future, like what we have been doing now with Python, I think that is a good way to make Qt part of what people think about when they are thinking about software engineering, building applications, building valuable user interfaces. Personally, I think being part of the Qt project, being part of the Qt community is not just good for the growth of the project itself, but also it's a good personal growth. The software development problems that we are working on in the Qt project are interesting software development problems. It's a very diverse set of problems. User interface, I talked about it, connectivity, networking, protocols, security, database development. There is so much stuff that you can work on in Qt. It's hard to think of someone who doesn't find anything that's interesting in there. And of course, having Qt on my CV at least has been a very useful part of my personal growth as well and professional growth. So yeah, ultimately having an ecosystem that then collaborates together and builds Qt together and brings that mind share and these reusable aspects of software components into the space. I hope we can continue to do that together and I would really like to invite all of you to be part of that. You are already by being KDE and by using Qt actively and yeah, perhaps over the next couple of days you want to talk to me about things that you think we should do in Qt and how you can participate in the development of that. I see a few people in the auditorium today that have been actively participating in things like the text-to-speech engine development in the QML development, in Qt Quick Controls development, many other aspects of Qt. So thanks a lot for that and that's what I had. So now I would like to hand it over to Pedro who is with me today to talk about what we are doing more than just thinking about the future and roadmap in terms of community. Pedro, over to you. Thank you. It's a weird moment taking off your mask in front of an audience. I feel so intimate. I cannot really walk around, can I? No. Yes, does the computer know how it works? Hello everyone. Welcome to probably the least technical talk of Academy 2022. My name is Pedro Bessa. This is my introduction, that's very clear. So who is this guy? Who is me? Who am I? I don't know. So yeah, I've been working at Qt company for seven months now. Let me use the microphone. And I've met quite a few people from here already. I guess most of you, I don't know. But basically I've been managing community management at the Qt company. So first of all, I'd like to tell you a little bit about myself. I come originally from Brazil. I already lived in Italy and now I am in Berlin. And I have worked in different companies. I have taught languages. I have worked in NGOs and gaming. And now I'm working at a software company. So that's quite interesting. So yes. Can I start with this thing? Hello, oh. Hello, testing, yeah, working, okay. Good, I have to walk, otherwise I get anxious. Okay, too much information. But I need to also pass the slides, wow. Well, I've done that to myself. So this is the guy. So what is community management? What does it actually mean? So I don't know how interesting that is for you. I mean, that is obviously quite interesting for me. But community management is something that has arised from the gaming industry. That's where online communities really came up and that people really started to really take a look into it and build the strategies and really make sure the resources that you have can accomplish a certain goal that you have. So yeah, I guess that's a very good, concise explanation. Also, do I need to leave time for Q and A's? Yeah, do I need to leave time for Q and A's or? Okay, I'll try to best concise as possible. So the community goals, what do we want to accomplish? So of course, by the end of the day, summarizing, yes, thank you. So at the end of the day, we want more contributions. We want more contributors. We want everyone to be happy. But that's very end goal. So how do we accomplish that? What do we want to see happening? So, okay. So what do we want to see happening so we accomplish those goals? Next. Please. Teamwork. So that comes with our community plans and the things that I've been drafting. I don't have much time to tell you about that. But our plan is to really give the power, the governance to the community and really make you understand that we can work together on this and I'm on your side. So some things that we really want to support in the meantime is local meetups. So people who are interested in organizing them, if you're ready, organizing them, let's talk. As you can see, we are supporting conferences. I have some people in contact with me that they're doing their planning their conferences so we can support them. We can sponsor them as well. But what I'm really interested in is getting that feedback from you. I really know what we can do from the Qt company side of things so we can get this community thriving. So, your feedback is really important. I'd like to know what you think and we don't have much time. And also, if you want more details about the plans, at least for next year, we can talk during the break or you can ask me some questions, you can write me, just contact me. Just so you know, the plan is to, I hope so, to have more people in the community department next year so we really get things going because I'm only one and then I can only do one thing at a time. So yeah, I think that's it. And I hope you have questions, I hope we can talk, I hope we can share, share, not share. I hope we can have a beer or two or coffee or water or juice or whatever. So yeah, this is the end and I hope you have questions maybe later, I don't know. Thank you very much. So there are a couple of questions online already and of course, if there are any from the audience, please raise your hand or shout, you can work with that. Mario asks, is there any work or research on speech recognition in Qt? Yes, we got a lovely contribution actually during summer from a chap called Xavier. I think contributing integration into different speech recognition frameworks to the Qt speech repository. So there will hopefully at some point be a Qt speech to text module as well. I have not yet had time to review that in detail but I'm very, very grateful for the contribution to first place, it's something I was thinking of as well when I was working on Qt speech earlier this year that this would be, there are a couple of things I would like to do still with Qt text to speech for perhaps Qt 65 or 66 but yeah, having speech recognition in Qt having every application able to be operated or dictated into using speech I think would be fantastic, yes. Great, thank you. Question from the audience? Can you come forward or maybe shout or I can go to you maybe, I don't know, sure. Hello, he's a person that deals a lot with clouds and DevOps, how does Qt will like, there is a, how the, there is a research inside Qt for observability because it has like, I use Node, Python and they all have tools that integrate quite easy with the cloud and Qt is like C++, it can crash and stuff like that. There is research like to make the, like I use a Flando like tools for observability to integrate with Grafana and other tools. Tools for observability in Qt and in C++ especially. As we develop Qt, I think more and more people become aware or as we maintain Qt, people become more and more aware of the value of the categorized logging we have in Qt today to really understand what's going on if in our CI system, for instance, a test is failing, it will be rerun with logging categories enabled for all things, which is a really important tool for us to understand why the test failed, what happened there, especially when we are sitting on top of non-deterministic systems like the window manager on X11 or on Wayland. So yes, Cish, maybe a little bit. There are things that we are looking into, especially for observability of software that is running on a device. We know that from the experience of our own professional service engineers, for instance, or people otherwise in the field, knowing what is going on when the frame rate drops of your 3D animation on your embedded board. What is the GPU busy with at that time? What's the CPU busy with? So profiling tooling, I wouldn't necessarily put that into the DevOps space as in you're developing a system and really need to know what's going on and how the system behaves. But even on that micro or not, on the very local level of observability, knowing what is happening in your Qt-based software stack, I think is something we have, we can do a lot more on and we are doing a lot more on right now, especially focusing on profiling on the graphic side and like categorized logging, like I mentioned, incrementally adding more of that. We still have from the Qt one day, I think some old, if deffery around debug and ablement. So you need to rebuild Qt with that thing set and then you might see what's going on. So transitioning that over to categorized logging so that end users and operators of Qt-based software have the ability to know what's happening under the bonnet is I think, yeah, it's something we are doing not very systematically. I'd like to learn more about where you are using Qt, where you specifically have that problem and what we can do to add more to it. Hello. Thank you very much for the answers, that's all the time we have in the schedule. But you're staying around, right? People can find you here, ask questions, do you have a table somewhere here? Yeah, so if there are any outstanding questions you can find the guys here and they'll be more than happy to answer any questions, I'm sure. Thank you very much again. Thank you.