Instead, I wanted to back at a much earlier time, perhaps a simpler time, was Academy 2019.
That was the first Academy and the first time we were talking about the then
upcoming release of Qt 6 and what that means for us.
We had a both where we brainstormed some initial ideas of where we want to go with this transition.
And we decided we need a sprint for this. So in late 2019, we met in Berlin
for a sprint, which, as far as I remember, was our first hybrid sprint,
and discussed some topics around Qt 6 and Framework 6.
And one of the things we did was set out design goals for KDE Framework 6.
One of them being we want porting to Qt 6 and KF6 to be as easy as possible,
which is also something that Qt wanted for their 5 to 6 transition.
And we wanted cuts in the API to be clear and don't have any surprises and be
as intuitive and ergonomic as possible.
And we wanted to delay the point where we are in a phase of active breakage
as much as possible and do a lot of the work we want to do very early in the
process on top of the existing code base and only at a later point go all in
on jumping on the new thing.
Then of course we wanted to improve our APIs make them more intuitive easier to use harder to misuse.
Then we wanted to drop some old ballast things we don't want anymore or don't
want to, can't maintain anymore, concepts that are broken or obsolete and generally
not ready for the future.
Then a lot of our stuff is built on Qt widgets, but there's more and more apps using QML.
And we wanted to have a clean separation between API that is for either of those
toolkits or or that is common between those two and can be shared.
Then we wanted to improve the cross-platform support of our APIs and make it
easier to build apps for Android, Windows,
macOS, and so on, which sometimes means having a cleaner separation between
an interface to something and the implementation.
So how did the time continue? In late 2020, there was the first Qt 6 release,
and naturally it didn't take very long for us to start building against that.
In the initial phase, this was mostly done ad hoc without much coordination.
And it was only in 2021 that we started doing things properly and introduced Qt 6-based CI builds,
which then allowed us to actually start actively porting things while still
keeping compatibility with Qt 5.
Then fast forward a bit in January 2023 we started branching out KF6 which mostly
meant creating a branch for Frameworks 5 for that to be continued in that branch
and from then point on master was Qt 6 only.
Soon after that Plasma and some other projects also started doing that but applications
for the most part kept building against both at the same time.
Then last year at Academy in Greece was the last talk I gave on this topic and
back then I promised that was going to be the final talk about this topic which
turned out to be a bit of a lie. So sorry about that.
And I raised the question of, are we there yet?
So then in November of that year, we had the first release of what we then call
the mega release, because for logistical reasons, we decided to release Plasma 6.0, Framework 6.0,
and the gear release at the same time, which was necessary because there's a
lot of subtle interdependencies between all three of them.
So releasing them together made things a lot easier to manage.
In December, we had the betas.
In January, we had the release candidates for them.
And then in February 2024, at long last, almost five years about talking this
initially, we had a mega release.
Some applause would be nice.
So how did our users receive this
mega release in a
lot of ways it was received very positively people liked it it was cool we had
cool features and what particular what i particularly liked is that during these
alpha beta and release candidate releases a lot of people were testing it that
usually aren't testing or pre-releases.
So there was a lot of interest and a lot of activity around that topic.
And the community was really looking forward to it.
But, of course, not everything was perfect. There were some bugs in the initial releases.
Not as many as in previous transitions, but more than zero.
We also made some design decisions that proved to be or were expected to be
controversial, like dropping certain features,
changing some defaults, or using Wayland by default.
Which is something we did for Plasma 6.0.
Then, unfortunately, a lot of distros had somewhat broken rollout of all of this.
During the alpha and beta phases, we worked quite a bit on creating packaging
recommendations and guidelines for shipping this release for distributions,
because it really wasn't trivial.
There were a lot of subtle things to watch out, and projects that needed to
be built against both Qt 5 and Qt 6.
So we wanted to make sure that this is as smooth as possible for distributions.
Which mostly worked out, I think.
There were two major problems. One of them is being the initial rollout of 6.0
in Neon was very rough and had some quite major bugs,
which mostly came down to very neon specific process problems and I'm not quite
sure what to do about it but it was already discussed in a sort of post-mortem
session on the neon side.
And then the other big problem was that certain distributions Arch were deliberately
ignoring some of our packaging recommendations.
Which mostly meant not shipping
various Qt 5 support integration packages by default which caused broken support
for Qt 5 applications and we got a lot of bug reports and complaints and support
requests about this but it was just Arch being Arch.
And another thing that wasn't quite good is,
a lot of the APIs in Plasma targeted towards third-party developers like Plasmoids,
Quinn Effects, Quinn Script had breaking changes and we weren't always good
about documenting these.
So naturally a lot of people wanted to update their third-party content to Plasma
6 but often didn't have any documentation on how to do that which caused understandable frustration.
So, looking a bit on the API side, did we succeed in our design goals?
On the positive side, we had a lot of simplifications in our frameworks and in Plasma,
which meant that some things that previously would have been very hard to implement
or fix were now easy to do.
This is something mostly I or other people involved in this process noticed,
because we know what we did and how it was before.
But the thing is, a lot of people coming after us won't even notice that,
because they just see, okay, it's easy, but they don't know all of the work
that went into that being easy.
On the negative side, we had a few API design decisions that turned out to be
problematic in some ways, because they weren't obvious to use and hard to misuse,
which caused some bugs, more than I would have liked.
And some of these API decisions were done by myself, so I have no one to blame but myself.
Then during the initial phase of deprecating things and then introducing a replacement
for something, then deprecating it, then putting everything away,
I think we did a quite good job of documenting all of this in like deprecation documentation.
So people generally knew how to port away from these.
But there was a phase where we stopped doing that because master was KF6 only.
And we were in a phase where we allowed ourselves to break APIs with auto-proper deprecation process,
which made a lot of things very easy and convenient to do for us that otherwise
wouldn't have been possible, but we didn't always do a good job of documenting this to,
people porting after us.
We had a policy of if you drop something,
you need to port all of the users that are currently on KF6, which worked okay,
but if someone didn't port
at that time but is porting now they sometimes run into problems with hey how
do i actually port this and we don't have any documentation for it and the documentation
for the general reporting process was mostly a bunch of academy talks from me
but not much in written form.
But try finding that commit three years later when you're forwarding something.
It's a lot of work that shouldn't be necessary.
Then during the initial KF6 print, we created a very large workboard with a
couple of hundred tasks on it of things that we want to do.
We didn't get to do all of them. some
of them because we decided okay this is not worth doing
actually some of them were decided
okay we don't actually need to do this now we
can always do it later and we don't need to break api for
it but for some of them we just missed the window
of doing them because too many other things to
do and the whole process already took enough time and we didn't want to definitely
delay it until everything is perfect so at some point we had to ship because
it got unsustainable to just keep iterating on on unstable master and eventually
we just needed to ship something,
and similarly we had a lot of to do kf6 comments throughout our code not all
of them did get addressed, so they're now in good company with some of the to-do KF5 comments.
And somewhat recently, we introduced the first to-do KF7 comment.
And some of the API changes in particular, that's something we noticed in Kirigami
came quite late in the process, which wasn't great because then we had to do
a lot of last-minute porting.
But that was also complicated by the fact that we had a pretty good strategy for evolving C++ API.
Introduce a replacement, port all of the users, deprecate the old thing,
and then at branching, remove the thing.
Worked out quite well. For QML, that was
a lot harder because all of the deprecation warning markup and if-devs and compatibility
builds don't really work with
QML and you don't have a good way to do version-dependent code in QML.
So it was very hard and basically next to impossible to have QML apps work against both Qt 5 and Qt 6.
Which is a fact that I lamented quite a lot.
So this week at the Contributor Summit, we actually had a very good conversation
with some of the QML people about how they can or we can support this use case better in the future,
which is going to stay relevant even when most of the transition is done by now.
Talking about challenges, we had a few. First and foremost, while this transition
was nowhere near as painful as previous transitions, so I've heard I haven't
been part of any of the previous ones,
it was still a lot of work because we have a lot of code.
When I'm doing presentations for different audiences than just KDE,
I like to introduce ourselves with, we have about 15 million lines of C++ in QML code. That's a lot.
And even if there are only small changes needed, if you multiply that by 15
million lines of code, that's still a lot.
And sometimes you need to touch
code that you really don't want to touch because nobody understands it,
but you need to touch it anyway because it uses something that doesn't exist
anymore or you want to get rid of a certain API or any reason.
And sometimes that took a bit of a leap of faith and a lot of blood,
sweat and tears to make sure it keeps working.
Then we also depend on some third-party modules that are also based on Qt.
So we also needed Qt 6 builds of them, which in most cases wasn't much of a
problem because upstreams were receptive about,
either did it themselves or were receptive about us porting them to Qt 6.
In some cases, it took a bit longer than necessary for them to accept and release our changes.
We still have some libraries in the K account stack that aren't released against
Qt 6 yet, but basically distros now ship our sort of fork of it.
But it worked out okay enough in the end.
Then when Qt 6.0 was released, there was a bit of functionality missing that
we were previously using that sometimes was clear, okay, this is not coming
back because it was deprecated before.
And sometimes we had to lobby them into adding back some of the APIs that we needed.
And by around 6.5, we were mostly complete on that front.
And the first release of
the first mega release was against Qt 6.6
and to keep
supporting Qt 5 we had to create the
KDE patch collection because Qt 5 was closed for contributions and the LTS release
was commercial only and open source was delayed by a year so we needed a way
for us to have patches for Qt for bug fixes that wasn't upstream Qt,
which worked out okay enough,
but it was a hassle that I would have liked to avoid.
So with us being there yet, the obvious question is, what comes next?
And before we get into that, we need to ask ourselves, are we actually really there yet?
While it's true that we have had the mega release and a lot of our applications
and Plasma built against Qt 6, we still have some of them that built and released against Qt 5.
That's a problem because, well, here it says Qt 5 is out of support.
Today I learned from Volker Hilsheimer that this isn't actually quite true because
there's still a small amount of things going on there and getting released.
But for all intents and purposes, consider Qt 5 dead.
And Qt 6 in many ways is just better, even if your application isn't actually
using any of the new API. Some of the improvements under the hood makes the
experience of using them just a lot better.
This is particularly the case of Wayland support, which improved a lot in Qt
6 and fixed some long-standing problems there, which is very important given
that Wayland is the default now.
Then moving on to KO5, it's still technically officially maintained and released,
but in practice not a lot is happening there.
So, while it's still possible to get bug fixes in there, very few people actually
do it, so it doesn't receive much improvement, while KF6 is very actively developed.
And it pains me to admit it, but support for running Qt 5 applications in an
otherwise Plasma 6 session is also subtly broken in some cases.
For example, anything that relies on plugins needs those plugins to be built against Qt 5 and Qt 6.
And distros either don't ship them or we don't even provide them properly upstream.
So there's a lot of subtly broken things here and there. that just work fine
in a completely KF6 session.
All of this raises the obvious question, do we or can we or when can we drop
support for Qt 5 in our CI infrastructure,
in our build systems and so on and so forth?
I do not have the answer to that. A large factor we need to take into account is
that there are still distributions out there that ship Plasma 527 and KF5 and KF5-based apps.
This includes also this year's Ubuntu LTS releases, which for unfortunate but
understandable reasons doesn't ship Plasma 6 yet.
And that will be supported by Ubuntu officially for the next two years.
I'm not sure whether we can afford to ignore that.
So that's perhaps something to discuss this week or the next weeks, months and year.
We could.
Okay, what's next for our software platform?
So to answer the question of what is next for the KDE community,
we just elected some new goals, which is generally the best indication of what's
next for us as a community.
As it stands, my personal goal proposal got selected, which is all about improving
the application development experience.
And naturally, there is a huge overlap between that and all of the work we've
been doing on modernizing and polishing and porting to Vue 6 our frameworks and software platform.
And generally, we should just continue what we've been doing in the initial
phase of the Qt 6 port, which is just finding APIs that are problematic and we don't like anymore,
introduce replacements, and deprecate the old thing.
It will probably be a while until we can drop them, but at least having them
deprecated means it will be dropped eventually, and it tells people,
this isn't good API, don't use it.
Then a topic that keeps appearing again
and again is Wayland we made Wayland the default which was a somewhat controversial
decision but as far as I'm concerned it was the right one and according to our
user feedback statistics about 80% of Plasma 6 users are using Wayland right now.
Wayland still isn't perfect effect and we as a community need to come together
and address those problems.
Historically it has been mostly the case that most of the work on improving
the Wayland experience have been driven by a few plasma and quinn maintainers but this doesn't scale.
So most of the big issues in Wayland are addressed by now or in the process
of getting addressed but there's still a very long tail of small quality-of-life
annoyances and things that are subtly broken.
And it can't be the responsibility of David Edmondson and Flood alone to fix
all of the things in Wayland.
And we as application developers need to watch out for things that we can do
in our application code to fix those little Wayland annoyances.
Because in a lot of cases, it's the application that's wrong,
not the toolkit or the compositor.
Then earlier today david was
talking about flat pack snaps immutable
distros and sandboxing which according to
him and i very much value is his opinion is one
of the things that we should be watching out
for and focusing on for the foreseeable future which
is something i can very much agree with and as
David mentioned in his talk there's quite a
few things to be addressed there and there's
the seemingly never-ending debate about the merits of Qt widgets versus QML
where I don't see either of them going away anytime soon but the trend clearly
indicates that the favors are tilting towards QML.
And we need to find some sort of answer to where do we want to position ourselves
in that regard with our software platform.
Then we just completed one transition, mostly anyway. What about the next one?
Historically, it has been the case that these major version transitions have
been driven by Qt releases.
And this one has been no exception. But it also has been multiple transitions in a trench code.
We had an API break in Qt.
We had an API break in frameworks.
We had an API break in Plasma. We had a sort of user experience break in the
sense that we dropped some things, we changed some defaults,
we made Wayland the default, we made some design changes.
And all of that, or not all of that,
is something that would be neatly justifiable in just a minor release.
So having a 0.0 release afforded us some leeway to do bigger changes that otherwise
would have been more controversial.
And we did the valent by default thing. All of those were done together at the same time.
There were good reasons for doing it that way, but it doesn't necessarily have to be that way always.
Here's a few questions I want to ask, and I don't really expect any answers to them right now.
I also don't have anything concrete to propose. I just want to give you some
food for your brain to think about some things for the foreseeable future.
First of all, will there be a Qt 7? I asked the Qt people.
Okay, that's surprisingly specific.
Is that just extrapolating or?
Thank you.
Right so the big
thing is nobody knows what's gonna
happen there may be maybe that
alan is perfectly on point with his extrapolation it
could be that five years from now we are all writing electron apps so we don't
really know we should prepare for the future where alan is right and And we
have a Qt 7 release somewhat soon.
But it doesn't have to be that way. Then something we noticed by doing all of
this work with breaking stuff, breaking stuff is actually very fun.
Because as I mentioned, things that were once hard are now easy.
And doing some things becomes a lot more easy or even feasible in the first
place by making breaking changes, which raises the question,
should we do that more often?
Because historically our compatibility cycles in Qt and in frameworks have been
very long, close to a decade in a lot of cases.
It doesn't have to be that way. I'm not saying we should abandon API stability altogether,
but we could meet somewhere in in the middle and have, for example,
a API break once a year or every two years. It doesn't have to be a decade.
Also, something Qt and frameworks provide is ABI stability.
Which I want to raise the question of how valuable is this to the people that
are delivering our software,
which is mostly Linux distributions or ourself via some sort of bundled format,
whether that's Flatpak,
Windows installers, Android APKs.
Is do we need API stability for this?
And if not, what kind of nicer things would this allow us to have?
And is it worth the cost of changing the stability guarantee?
And another thing David mentioned earlier is how does Flatpak and Snaps and
immutable distros change all of the assumptions that we previously had and that
influenced the way of us doing things.
For example, we have a lot of functionality and integration points that basically
assume we have a Linux distribution with one version of Qt installed and everything
is built against that particular Qt.
Basically, all of the plugin mechanisms rely on this fact. This already broke
when we introduced Qt 6 in addition to Qt 5, which caused us a lot of headache.
Now that we have containerized formats like Flatpak that do ship their own version
of Qt, a lot of the plugin integration doesn't work anymore.
And another aspect of Flatpak and all of the others,
I don't want to single out Flatpak here, is that they ship their own version
of Qt so we can actually very easily have different versions of Qt or frameworks
or any toolkit installed in any given system,
which means that breaking APIs in there actually becomes a lot more affordable
and might influence on how we see those stability guarantees for our libraries.
But as I said, I don't have any concrete proposals here.
I'm not advocating for breaking all of our stability guarantees tomorrow.
But I'm looking forward to having your thoughts on all of this and where to
go next with our software platform. So, thank you.
So, thank you, Nicholas, for your presentation. And, yeah, do you have questions?
Okay um yeah uh
you mentioned that the sorry um
the documentation changes
and the portal uh the missing documentation for for
porting um personally it
it would have been easier for me if at least the kf5 documentation would still
be available somewhere because kd lips for documentation is still online but
kf5 is not so do you have any plans to maybe add that,
okay there's two answers to this one of them is it should be fairly easy for
somebody like ben to add the kf5 version as a read-only copy to the archive,
The second answer to that is, we did consider, can we provide both of them at
the same time, which turned out to be very hard given our current documentation infrastructure,
which is why we didn't do it, because nobody felt motivated enough to put in all the effort.
What I am currently working right now is porting all of our documentation from Doxygen to QDoc,
and this would actually make it a lot easier and it's something that I'm actively
looking out for to provide multiple versions of documentation in the future.
Whether we are going to go through the effort of converting the existing KF5
API mark up to the new format to allow that, I don't know.
It would take someone very motivated to do that so I'm not going to promise
that. but at least looking to future transitions this should become a lot more feasible.
Any further questions? I think over there there is a question,
So before my question, I have a couple of comments, one of which is that your
remark that Arch was being Arch could be said to have been a rather Arch comment.
I just want to comfort you a little on one point, which is that you said you missed some to-dos.
In the rush to the Qt 6 release,
we had a mad rush to deal with a whole lot of,
hash hash hash qt6 to do
comments and we did get
quite a lot of them but um some of them had to
be turned into qt7 ones so you're not alone this this is just how big releases
go um and um we have adopted a policy which you might want to think about for
future reference which is we now as far as possible if it is something to change
at the next major release we actually say.
Hash if qt major
version is less than sorry it's
greater than equal to seven or we're in a bootstrap
build do it the future way hash else
do it the modern do it the current the old way the way
we're still doing it so that when we hit qt
7 we will automatically make the transition the all
bootstrap similar in some cases the all
bootstrap is there so that we will actually see most of
the breakages before we get there well we
don't have a bootstrap like that so that's not
going to be as practical but yeah you do have a good point it's something we
could have potentially used a lot more finally to my question you mentioned
touching some scary code did you record all the places you found scary code
in a big list of come back with the flamethrower?
Not explicitly.
This. This was actually a major reason of why we went through the trouble of
killing a lot of things in frameworks because it was scary code.
And actually the mere thing of
going through all of the code and looking for things
that we could potentially do without was at least for me a very valuable lesson
in getting to know our code base better because now I have a very good overview
of a lot of the frameworks code that I didn't used to have even if not in all
cases this resulted in actual changes being made.
But the list is still somewhere there might be a good idea to formalize that ...
So actually we're talking a
lot about kde in itself but also
there are external applications which use frameworks and cute and actually from
debian there's a lot of cute five stuff still available which isn't ported yet.
So thinking about when to break API again, it will also,
happen that external applications get broken again and distros need to work around.
So this is really also something to think about that things are used externally.
Yes that is a very good point and if we decide that having a more relaxed approach
about api stability is the way
to go we probably want some sort of formal communication channel for that,
and somewhat related to that you you bring up a good point with third-party qt5 applications
which is we have quite a few things that are only there to hook into Qt and
provide some integration bits like plasma integration or breeze and oxygen styles and so on.
So the decision of when to retire the Qt 5 versions of them is not only influenced
by how many of our applications are ported but also how many third-party Qt
5 applications are still out there and they're implicitly using these things.
Okay. So, yeah. Thanks for the presentation and questions.
And we are now running out of time.