Hello everybody, my name is Volker Hilzheimer, I'm the Chief Maintainer in the Qt Project.
I have seen some of you at the Contributor Summit that we had in Würzburg here earlier this last week,
where I also talked a little bit about what I think is the future and the challenges
and the opportunities for us in the Qt Project beyond 6.8.
This presentation touches on some of the same points, going a little bit deeper
into specific work items and technical bits and pieces, but it's not a very
technical presentation.
Yeah, beyond 6.8, we are about to release 6.8 during September,
perhaps in early October.
We have a couple of pending header review discussions.
Those of you who are contributing might be aware of it, but I hope we get those
resolved fairly soon and then can ship 6.8 as the next LTS release.
Let's talk a little bit about what the highlights are going to be in 6.8.
Of course, before we start thinking about what's happening next.
So in 6.8, we did a whole bunch of stuff related to general UI improvements
that are relevant, I believe, for KDE, such as, for instance,
an application can now actively request dark or light mode.
We have more controls over certain aspects of font selection.
We have better support for vector graphics, such as SVG rendering.
Hatem here can give you the details on that one.
Qt Quick on the desktop has been a big focus for us now in Qt for several releases.
What we are introducing in Qt 6.8 is a better integration, or actually an integration,
into the native menu bar system on macOS for menus in Qt Quick.
So we used to have these platform lab stuff that you might have used before.
Now the menu and the menu bar that we have in Qt Quick is actually talking to
the menu system on Mac OS.
We are also doing some work on pop-ups in general so that they,
on the desktop, are not items within the QML scene, but rather top-level windows,
like you would expect from a dialog, for instance,
um thank you for the feedback from the kde community that we got in that respect
the defaults changing defaults like that is of course always a bit problematic
and confrontational because it suddenly changes existing user interfaces which
is not always um an improvement.
But yeah both although on the layout management making layouts and controls
behave differently or behave like you would expect it from resizing windows
for instance which control should get that extra space.
That is something that the layout system and widgets had for many years and
MQt quickly so far haven't had that.
So we make a couple of additional facilities in that one and also some of the
item views that we have the table view, preview and so forth have now better
control for certain interactions.
On the scene on Qt graphs data visualization that has been a new module that
is replacing over time Qt data visualization and Qt charts into a module that
is sitting on top of the modern Qt 6 rendering stack and the QML scene graph.
So this is something that is now moving out of Tech Preview, which is great.
A whole bunch of work has gone into networking support and web service consumption
APIs in Qt so that you can easier work with distributed systems using gRPC,
using Protobuf, and also running your own HTTP server.
That has been work in progress for several releases, So now we are taking those
out of tech preview, which is great.
And Qt Multimedia, a bunch of work has been done there to both allow you as
a programmer to define your custom pipeline using programmatic IO APIs,
feed your own images, for instance, into an encoder, or decode images or audio
into PCM data that you can use for post-processing.
And perhaps interesting for you, support for Wayland. Somewhat experimental
still, but for screen capturing.
So that's not everything that we have in 6.8. Look at the documentation.
There was a new page on the snapshots to get the whole shebang.
This is what I consider to be the highlights.
So what are we now going to do beyond all of this?
Are we done already, or is there more to do? I think there is more to do.
So beyond 6.8, we want to definitely make it easier to use Qt Quick and use
QML for anyone out there.
Right now, we have a very strong focus, of course, on C++, C++ developers using
Qt and also then using QML and Qt Quick to build their user experience.
We want to support more languages and we want to make that technology,
Qt Quick and Qt QML, to more developers.
We want to reach people that are developing software in Python,
in C Sharp, that are building Android applications.
We have earlier seen from Joshua, I think, the Rust talk, which I think is going
to be super interesting for us
as well how we can make it easy for rust developers and rust applications,
to use um qml for their or qt quick
for their user interface so that allows us to reach a whole new group of developers
that we are not accessing and not able to talk to or or make any anything interesting
for today it gives hopefully qml a big boost in new people that can actually
understand that language and develop in that language and qt quick of course
as a great user experience
technology also from a starting perspective.
We saw some of that earlier in Ariane's talk.
Yeah, we want to.
Focus on more things related to workflows as well.
So turning Qt into an open framework that is really available on any kind of
development environment.
So it starts with the tools, it starts with the development experience.
Making it easy for people that have existing code to use Qt and Qt Quick in
their application, even if it's not a Qt application.
So you have perhaps seen the blog that we are allowing, that we are now making
it easy for people that have a .NET application to use Qt Quick as well on top of that.
So these are the kind of things you want to make really easy.
One challenge that we see, and I think we also see that or you see that in KDE,
and we got that feedback already during some of the discussions over the last
day, it is not a perfect developer experience yet to build a Qt Quick application.
It comes with a certain friction and a certain overhead to have both your C++
entry point and your application logic, and then you need to get the QML and
the Qt Quick Code in there.
You have a hybrid kind of development environment.
How can we make that easier? If we add more language to that,
that doesn't necessarily make that easier just by itself.
It just makes it easily or similarly hard for everybody.
So making that experience easier by having a better concept of what could a
Qt Quick or QML runtime look like, where we can package a whole bunch of source
together into a well-defined format, so it's easier to deploy these things.
So these are things that we are thinking about, making it easy for a hybrid
application built with multiple different technologies, multiple languages to
be packaged up, deployed, debugged, iterated over.
Technically, a big part of that is also making it easy and possible to combine
different UI technologies.
So we just heard in the previous talk about widgets, SVG, Qt Quick.
We have native frameworks, of course, on the different platforms,
on Android or on iOS or on Windows or on macOS or different systems used to
build applications, also on Linux desktops, of course.
Can we make it easy for people to combine those different technologies into
a consistent user interface, into a consistent user experience?
So the problem that was just earlier described about, okay, you have a QUIC
application that's using a style implemented using QUIC technologies.
You have a widget application using the same style implemented using a different technology.
Imagine that when people are combining Qt Quick and Qt Widgets inside of the
same application, inside of the same user interface.
And that is something we want people to be able to do and make it easy to do.
Because there are lots of widget applications out there.
There is nothing stopping people,
hopefully, from using Qt Quick for some aspects of the user interface.
Putting a Qt Quick widget inside of their widget application and then running
your QML code inside of it. How many of you are doing that? How many of you
are using Qt Quick Widget today?
Unfortunately. Okay, so we want to make this easier.
We want to make this less frictionless. Qt 6.8 has a lot of good facilities
there to combine Qt Quick and Qt Widgets.
But then, of course, you want to have a consistent user experience.
Your button on the widget side of the application and your button on the Qt
Quick side of the application should look and behave similarly.
You want to be able to tab from the widget side of the application through the
Qt Quick side of the application to the widget side of the application again, right?
Tab focus, accessibility, modality, all these user interface concepts,
drag and drop, they need to just work.
So that's a bit of work for us beyond 6.8 now, figuring some of these complexities out.
And yes, also, of course, thinking about what kind of unified styling architecture,
could we have so that you or users otherwise that want to have a custom style
or where we want to make sure that the entire application follows the native
look and feel on macOS or iOS or Android,
that we have a consistent look and feel across the entire application.
That's a really hard problem, as we just saw.
Lots of good ideas already in many people's heads, so I hope that's a good opportunity
for us to also collaborate on that one.
All right, so that's one big topic for us, making Qt an open framework that
is also easy to use if Qt doesn't own the entire process or the entire screen.
Then there is, of course, a trend that is very important for us as a cross-platform
framework used in many different industries, used in many different geographies,
and that is just simply computing fragmentation.
So both on the hardware side and on the operating system side,
we see a lot of things happening.
ARM is now coming increasingly to the desktop. Mac OS has been or Apple has
been leading the pack on that side.
But we see it, of course, from Microsoft with Windows on ARM.
Linux on ARM is becoming more and more relevant, especially in Asia Pacific.
We see new architectures also in China, for instance, becoming important and relevant.
MCUs as a very lightweight computing platform is important for us,
and we want to make sure that people that know Qt can also target MCU devices
and architectures with our technology and with what they have learned.
On the other hand, we see a lot of convergence of user expectations,
at the very least, from mobile to desktop and into the embedded space.
People have the expectation that user is or user interface responsiveness user
interface design quality are becoming
more and more the same across all different computing platforms so,
tablets and laptops are more and more converging and harder and harder to differentiate
you see you see increasing amounts of of laptops for instance and also have
a touch screen or where you have mouse trackpad and touch screen all together in the same time,
KDE's goals on having input management be very well done, I think is super relevant for us.
And I think there is also not just a possibility to collaborate,
but a need to collaborate, because event handling, understanding multi-seats,
for instance, if you have multiple mice talking to the same,
interacting with the same application,
how do we express that correctly in the framework? So there are a lot of things that we need to do there.
And then there are, of course, completely new experiences and environments that
we are are working on, so XR for instance.
So there's a whole bunch of things that we are doing. I mentioned already hardware
architecture, operating systems.
Regional developments, staying in touch with what's happening in different parts of the world.
XR for us is a really big opportunity, making Qt a cross-platform framework
also across the different XR architectures or VR devices or VR platforms.
So we have MetaQuest, we have Apple with VisionOS, we have more different devices.
Coming now, and we want to make it possible for people, of course,
to create an experience on different immersion levels using Qt that allows them
to deploy that experience to different XR or VR or AR technologies and headsets.
And that's quite interesting because that comes with a whole range of new challenges
from a user interaction perspective.
It's no longer mouse or touchpad or touchscreen, right? It's gestures,
it's pinching and gesture recognition.
It's locomotion in a virtual environment.
So there are a whole lot of new things that we need to figure out and solve. And it's very exciting.
Some of you might have the opportunity to test out our XR support or VR support
at the Contributor Summit earlier this week.
So lots of good things happening there. And yeah, being a cross-platform technology
in this space as well is what we are trying to figure out. So there's a lot
of stuff that's different.
Some of it is not so different, but it's just a new platform.
So the low immersion mode, for instance, on the Vision OS is not all that different
from running an application.
But there are some differences still, and we need to make at the very least
sure that you can deploy a Qt application as a native Vision OS application
rather than as an iOS application.
So some work of that has already been done and will be released with 6.8,
but that is, of course, just the beginning of that journey.
And then we have also distributed software systems where the application front
end and the application back end are decoupled, like we know from the typical
web architecture or web service architecture,
front end being in Qt Quick, back end being wherever it is, on an automotive
device or a cluster, for instance.
It's not unusual that the security or safety critical parts live on a different
virtual machine on a hypervisor in the car and the more relaxed security requirement
UI aspects are living in a different virtual machine.
And then they need to communicate with each other over gRPC,
protobuf and efficient protocols.
So a lot of work happening there as well to make this distributed system architecture
possible and easy and cute as well. So it's not just UI, it's also about really system architecture.
Then there is the CRA, the Cyber Resilience Act that the EU is releasing and
imposing, let's say, on the software industry.
It's a great opportunity. It's a great challenge. It's both sides.
For us as end users, it's definitely a good service to have the cybersecurity
and cyber resilience requirements expressed in law.
For us as engineers, it's a great challenge and a great opportunity to solve
some of these problems and make it still a good and productive environment.
So we have been looking into the different requirements that come towards us
from the Cyber Resilience Act.
One of those is that we need to very clearly document what's in the box.
The SBOM, the Software Bill of Material. If you install or acquire a product
that comes with a significant software component, software is that,
but also a device that comes with software,
What is actually constituting that stack of software? What are you actually getting?
So we are, of course, part of that stack, and we need to make very clearly documentation
that our users can rely on that this is what they are getting when they are using Qt in their stack.
This is the risk that they are introducing by using a whole bunch of third-party
libraries, linking that back to, for instance, CVEs when they are getting raised
in the relevant databases and so forth.
So we are building a fair amount of software infrastructure around this right
now to make sure that we have an easy, unbureaucratic way of doing that,
of creating this metadata for our packages.
It's super relevant for us, of course, because we are a commercial supplier
of technology to our customers.
I think it's also quite relevant for you in KDE to figure out how can you do
that, even though you might not be directly as a project responsible for these requirements.
The CRA states that the first entity that is having a commercial benefit from
distributing software needs to be also held liable.
But yeah, I think you will have perhaps users that would appreciate if,
for instance, the SBOM of KDE would be available. And I think that is an opportunity
also for us to collaborate and work together with the entire industry.
How can we generate this information as much as possible automatically using
something that is manageable for us as developers that we can easily work with?
So if you see Alexandru at the Academy conference this week,
then he's a great guy to talk to about that.
For us in Qt, of course, there is more than just third-party libraries that
we need to make sure we keep track of.
We also need to look at our own code and understand what is the attack vector
that that code might introduce to an application or to a software system if
there is a bug or a vulnerability.
And we are focusing there right now on any part of Qt that is involved in processing
data that is not under the full control of the application.
So anything that might constitute untrusted and therefore potentially malicious,
intentionally malformed data that Qt is parsing, that Qt is processing without
the application having a chance to sanitize it first, to scrub it first, whatever.
That is something that we need to focus on from certain perspectives of software
engineering craftsmanship, let's say.
So, making sure that reviewers are aware of the fact that they are now looking
at a patch to code that is potentially introducing a vulnerability if there
is a bug, if you have an out of buffer overrun or something like that.
Making it possible for our CI system to focus the execution of fast tests or
of stress tests on those parts of Qt that change or that get changed during a commit review.
So, there are a number of things that we can do there to integrate with tooling,
but first we need to understand what of our code is actually potentially an
attack vector, and then marking that with the respective some comments.
That's a discussion that we have right now in the Qt project,
how we do that. It's perhaps something that also then would be,
could be relevant for the KDE project to adopt.
So, that's something where we would very much like your input as well.
And then yeah basic IT hygiene I
would say governance of the account or
life cycle of the accounts to the Qt project something where I would like to
have your input how are you doing it when people are no longer active with their
perhaps approver privileged account yeah at some point we should perhaps deactivate
the account remove those privileges
require a certain amount of re-authentication before we give a high degree of
privileges against the user.
So yeah, something that we can discuss perhaps in the whole way how you are
doing this kind of thing in your project.
All right.
Ecosystem and community is of course for us as a project,
critical to think about for us as a company. It's critical to think about as a Qt company.
How can we make sure that there is an ecosystem where multiple players find
it valuable to be part of,
where people can contribute with their skills, with their solutions,
with their knowledge, work together, build something together,
make sure it's a social experience where people don't feel that they are the
only ones solving that problem.
So we have, of course, a very rich ecosystem of Qt solutions out there.
Several thousand GitHub repositories
are providing solutions for Qt developers using Qt, building Qt.
In KDE, you have a rich set of frameworks that are to some degree usable also
for people that are building Qt applications that are not otherwise using KDE or depending on KDE.
We need to make sure that these contributors, these projects know about each
other and people that have that problem that this project is already solving
can easily discover those as well.
I think we haven't done a very good job with this in the past.
We haven't tried very hard.
So that is one of the things where we are focusing on right now within the Qt
project and within the Qt company, reaching out, trying to build these networks,
understanding who are you, how can we find you, how can people find you.
So one big aspect to that is, again, resonating very nicely,
I think, with the KDE goal that was
announced today about recruiting more contributors into the KDE project,
also by reaching out to the educational domains, the educational network,
building networks with schools,
with universities to make sure that the skills that we are looking for,
that you are looking for, are actually trained and are educated and are taught in schools.
So building this network, C++, Qt on the curriculum, using KDE as a project
where people can start learning how to build complex software systems.
I think that's going to be a very good collaboration if we can get that off.
And then otherwise, yeah, building networks with projects that are using Qt
today and that might be building libraries or frameworks that many other projects
or many other users are using themselves again.
That's something where I would very much like your feedback and like your input as well.
We have announced that for next year's Contributor Summit.
We have already tried that for this year's Contributor Summit,
but I hope we get a bit more momentum into that for next year's Contributor
Summit, having more open source projects,
joining that as Qt users as well, because the perspective that we got this year
from having so many people from the KDE project participating was really,
really valuable, and I really enjoyed having those discussions with you.
So I hope next year we can have even more open source projects that are building
technology on top of Qt and that are building technologies for other Qt projects
to become part of that discussion.
Share their perspectives with us and help us building that network so that we
can really make sure that the decisions we make in the Qt project ultimately
are also reviewed and discussed with that perspective in mind.
Because I think that's very important and we know that from the Qt 5 to Qt 6 transition actually.
How many Qt users have actually waited for the KDE project to complete the Qt 6 port,
which included the KDE framework 6 port and many other things of course,
but many of our customers and many of the other users out there have looked
at KDE as the lighthouse project when KDE has finished its project, its port to Qt 6,
then clearly Qt 6 is good enough and ready.
So I'm delighted and happy that it has happened and that you have earlier this
year managed to release Plasma 6.
And I think there will be many projects out there that have a similar importance
for many of our users, making sure that they are all supporting over to Qt 6.
And that only can happen and we can only support these projects if we know about them, of course.
Yeah, and making software development productive and fun has,
of course, been always the ambition of us in the Qt project.
Giving solutions that make it easy to write software, making it fun to write
software, making APIs that are hopefully intuitive to use and hard to use incorrectly,
solving problems that people have.
So the most important thing when we think about we are a tool for software developers
in the end of the day is, are you getting the job done?
Do you feel productive when you do the work? And are you having fun?
These are the three questions. If those are not answered with a clear yes,
then we need to do better in the Qt project.
So I hope that we are getting good or continue to be good at that and deliver
good solutions and that you are having fun.
The feedback that I'm getting here and the vibes that I'm getting here from
the conference about Qt and Qt 6 makes me feel good.
That's nice. But I think we still need to continue working on that,
of course, make sure that things are well designed, that things are well documented,
that we are also reaching new developers with new expectations in that respect.
The existing documentation we have is great and it's very technically correct
and you find all the things there about the API reference.
But younger developers might look at videos, might want AI co-pilot sessions
and so forth to be part of that.
So, yeah, we need to continue working on that, of course.
There are a whole bunch of things that we are working on now on the graphics and UI side.
So, yeah, vector animations, HDR support, hardware-accelerated 2D painting.
On the graphics engine side, on the user interface side, working with what modern
desktops give us as facilities for, for instance, transparent windows.
These like, effectful windows.
Qt content and title bars as well, so customizing the window frame,
that's something where I think, from the Wayland perspective,
we have a lot of things to work on together and already are doing that.
Docking widget support in Qt Quick. And yeah, we mentioned already the unified styling architecture.
On the core and non-visual side, we continue our work on the connectivity,
so making it easy to consume web services, networking generally,
looking also into what the C++ standard, of course, is doing with,
for instance, asynchronous API, sender-receiver, and so forth,
looking into push notifications.
Asynchronous I.O., we don't have a good API for asynchronous I.O. today in Qt.
File access on cloud storage on most modern platforms, You have perhaps a part
of your documents living on the cloud and on macOS, for instance,
that requires some certain facilities before you can access that as an application.
We heard already from Ulf about
things that we are planning to do for QML applications in the language.
And then, yeah, a whole bunch of tooling. Fabian mentioned many of these things.
Language server, for instance, making that better, integrating those into whatever IDE you want to use.
Also investigating what we can do with artificial intelligence technology,
large language models, can we train a large language model so that it knows
what good QML looks like, for instance.
Doing that in such a way that the provenance of that data is clear,
that we don't harvest all sorts of open source licensed software for that purpose,
but rather having a good control over that.
Your experience, the knowledge that you have with QML, for instance,
is also something that we can hopefully, perhaps, to some degree, rely on in that respect.
And then documentation and academy, in this case, the Qt Academy that we are
having with training material, with learning material.
Yeah, so hopefully some of all these activities are producing useful APIs for
you beyond Qt 6.8 as well, and making it more productive and fun for you to work with Qt.
And now I'm being shown that we have to start the question and answer session. Any questions?
You mentioned in the future there's going to be a hardware-accelerated 2D drawing API.
Okay, can you elaborate on that? Hardware-accelerated 2D drawing API.
Right now, we have a scene graph API that is fairly low level for people to
create something as simple as a rectangle.
Well, fortunately, we have a rectangle item in Qt Quick Control or in Qt Quick,
and we also have the Qt Quick Shapes module that allows you to do certain things very easily.
But for something, for instance, like the 2D graphs that we have,
like doing an oscillogram or some of these challenges is surprisingly hard if
you have to triangulate and tessellate all your stuff manually.
So having a better 2D Painter API that is more similar to what we have in QPainter,
but still generates scene graph nodes.
So there are some open source projects out there. Nano Painter, for instance,
instance is one of those that is popular and
we are trying to see okay what can we learn from that what what could we adopt
or what could we use similarly and to create a higher level um effective or
efficiently used 2d painter API okay I I don't want to run out of time any more
questions from other people, Carl?
I mean, that's a bit related, but one of my main points with QML and Qt Rejects
is that QML is super nice.
But sometimes you might want to move some parts to C++ for performance reasons,
for state management reasons.
And then your C++ API for Qt Quick is really, really small, the API surface.
Is there some plans to maybe include fewer items to this public API,
like for example, Qt Quick controls action.
Some really basic, I don't want everything, but a few more elements might be really useful.
C++ APIs for Qt Quick is something that we have fortunately avoided doing so
far because it has allowed us to change things in ways that would not have been
source or binary compatible.
But I think we need to start looking into, okay what what elements do we have
um can we have some more differentiated api commitments,
for instance we have now a number of apis in
qt where we say it's um it's uh
not fully source compatible over multiple minor versions rh i for instance or
the native interfaces so we could do something like that also for more cute
quick elements um but we need to be very careful and make very sure that we
know that we don't plan to change things in the future of course yes.
Question back there. So, basically related to the previous question,
what's the state of the widgets and how much effort is still going there or none at all?
Widgets are maintained and actively maintained. We have Christian Ehrlicher,
for instance, from the open source community doing a significant amount of work
to make sure that widgets and their styles are painting well on fractional scaling
displays that we have good high DPI support across all different platforms.
So on that level we want to keep widgets of course working and relevant and
continuously improve them.
We have made a number of improvements also to the rendering architecture on
some platforms to have optimized scrolling for instance.
We have implemented a Windows 11 look and feel.
Fluent WinUI 3, I think, is the official name of the design system for Microsoft.
So both on the Qt Quick side, we have implemented that style now as a Qt Quick style.
And also on the widget side, we have implemented a completely new style.
And if you heard the previous presentation, that was a bit or is continuing
to be some heavy lifting.
But we don't right now have any significant plans to introduce,
for instance, new widgets.
But yeah, contributions always welcome of course on the widget framework as well.
So extending patches for extending existing widgets with certain minor things would be accepted?
Yeah, right now we have an interesting patch for instance from a contributor
to make the header view in our
item view framework have a mode that is significantly less memory hungry.
QHeaderView right now creates quite large and complex data structures.
If you have millions of rows, for instance, in a header view,
then that costs, just the header view alone already consumes a lot of memory
because it needs to keep track of potential section movement and these kind of things.
And we have a patch under review now to introduce a new mode where certain facilities
are gone, but you don't allocate a gigabyte of memory just for the header.
So yes, these kind of things, absolutely interested, and contributions, like I said, welcome.
They don't necessarily, perhaps that's a different discussion.
Releasing things on top of Qt, making things on top of Qt discoverable also
if they are not part of the Qt framework itself.
If there are new widgets that people have created and that we know that people
love, then hopefully they can find them, but of course, again,
patches to existing code or also small additions here and there, absolutely.
Yeah, somewhat similar question, again, because I think it's an important topic.
So Qt Widgets is not as much the focus of development anymore than it used to be.
So we have that on the one side. And on the other side, we have things like
Qt Quick Controls, which don't really
seem to be that focused on desktop applications as Qt Widgets used to be.
So what is your vision for how development of desktop applications,
of traditional desktop applications are going to work in the next years?
Okay. The vision for how desktop applications should be developed with Qt.
Ideally, we get Qt Quick controls to be on feature parity with widgets.
So, like I mentioned, we have done quite a bit of work on the item views in
Qt Quick to support what would perhaps consider to be a hygiene factor,
but on a mobile device certainly hasn't been a priority.
Flipping or reordering columns in a table.
I don't know how many of you do that on your on a table on a touch on a mobile
phone But on the desktop it's clearly something you want to do so making these
use cases definitely possible also with Qt Click controls,
Has been the focus item views big focus on a big focus on that one desktop styles.
We took a bit of a shortcut with Qt 6 to basically implement the quick styles
for native Windows and native Mac OS by using the Q style code from widgets
and just making it widget independent.
Okay, that got us somewhere, but I think it's also a very limited architecture
and it's not perfect by any means.
The experience that we now have from Doris
and Carolina here for instance doing the iOS style as
a as a complete separate implementation of the
in Qt quick not using any
native api's from iOS to get the controls I
think that has taught us a lot and how we should maybe also do it
for the other side so that's one way of also making the Qt
quick styles for desktop better ultimately in in the mid-term and perhaps also
in the long-term because widget code will be out there and nobody should feel
that they have to toss all their decades of widget code and throw it away and
rewrite it in Qt Quick because we all know what rewrites usually end up as.
So rather accepting the fact that Qt Quick and Qt Widgets need to coexist and
should coexist and making that a good experience where people don't say in the
end, like, oh my God, I hate it, but at least I got some pixels on the screen.
So making that a smooth experience and a good experience is a bit of work,
both technically and architecturally, making the different composition modes
work, not making it perform well enough, and also, yeah, flexible and toolable.
That is ultimately also one big challenge with these user interfaces.
People that are using the Qt Widgets Designer, how can we make that Qt Quick
aspect also a well-tooled part
of it so that you don't have to learn two completely different workflows.
So yeah, work to be done, but I think in the foreseeable future,
a desktop application that is written partially with Qt Widgets and partially
with Qt Quick, I think is absolutely the reality and we want to make that good.
Yeah, for me, it was to not just say, oh, my God, I hate it.
I paraphrased.
On QQuick widget, we use it.
We depend from it a lot in the system settings app where some things are in
QML, some things are in QWidget.
One of the most painful thing
was the focus chain of keyboard navigation
so we have horrible things with event filter and
things that often breaks and so what are
the plans are there upstream fixes
the plan is to have it fixed in 6.8 i
think our daughter has is no
longer in the room but she spent quite a bit of time leading
up to the 6.8 release with with axel i believe to move
the whole focus chain logic into Q window so
it's no longer the the information about the focus chain no longer lives just
in the widget side and then we need to somehow merge it at at runtime so i think
it will solve runtime but i think we have now a more consistent architecture
that we have a single focus chain and so that we can actually know how to pass
focus through the different frameworks,
if there are bugs please let us know i'm would be surprised if there are no
bugs because this those new code our acts and see how it works,
but I love it already. Yep.
More questions?
We have two more minutes for questions.
Yeah, I mean, as you might know, I was the gold champion for accessibility two previous years.
And I wonder, like, if there's some plans from the Qt side to improve the accessibility
of Qt and Qt applications.
SVG? Accessibility.
Accessibility. Accessibility.
The goal with accessibility in Qt is of course that it just works.
We have been maybe focusing a bit too much on the plumbing and on the technology,
making it possible for people to write accessible user interfaces.
We have some pretty good confidence that it works and we have at least one KDE contributor,
Michael Wiechorn, that is doing a significant amount of work to make sure that
we support also some of the more recent additions to the accessibility frameworks,
announcements, and so forth.
So we have some new APIs in Qt 6.8 thanks to his contribution.
But I think, yeah, in Qt, we need to always be careful that,
okay, we make it possible for people to write accessible applications,
but is it also the default outcome of what people do?
Is it a steep hill to climb to actually make an application accessible or can
we make it easy by default?
So that's, yeah, there is work to be done.
A diverse community helps hopefully a lot with making that better.
So contributions always welcome and very happy that Michael is doing a lot of work there for us.
Okay, thank you very much.