1 00:00:00,017 --> 00:00:07,937 Instead, I wanted to back at a much earlier time, perhaps a simpler time, was Academy 2019. 2 00:00:08,357 --> 00:00:13,577 That was the first Academy and the first time we were talking about the then 3 00:00:13,577 --> 00:00:17,137 upcoming release of Qt 6 and what that means for us. 4 00:00:18,077 --> 00:00:24,637 We had a both where we brainstormed some initial ideas of where we want to go with this transition. 5 00:00:25,777 --> 00:00:31,597 And we decided we need a sprint for this. So in late 2019, we met in Berlin 6 00:00:31,597 --> 00:00:36,897 for a sprint, which, as far as I remember, was our first hybrid sprint, 7 00:00:37,237 --> 00:00:42,217 and discussed some topics around Qt 6 and Framework 6. 8 00:00:42,937 --> 00:00:48,577 And one of the things we did was set out design goals for KDE Framework 6. 9 00:00:49,257 --> 00:00:54,657 One of them being we want porting to Qt 6 and KF6 to be as easy as possible, 10 00:00:54,797 --> 00:00:59,277 which is also something that Qt wanted for their 5 to 6 transition. 11 00:01:00,197 --> 00:01:06,337 And we wanted cuts in the API to be clear and don't have any surprises and be 12 00:01:06,337 --> 00:01:09,517 as intuitive and ergonomic as possible. 13 00:01:10,197 --> 00:01:16,137 And we wanted to delay the point where we are in a phase of active breakage 14 00:01:16,137 --> 00:01:21,317 as much as possible and do a lot of the work we want to do very early in the 15 00:01:21,317 --> 00:01:27,377 process on top of the existing code base and only at a later point go all in 16 00:01:27,377 --> 00:01:29,057 on jumping on the new thing. 17 00:01:29,797 --> 00:01:36,097 Then of course we wanted to improve our APIs make them more intuitive easier to use harder to misuse. 18 00:01:37,515 --> 00:01:43,195 Then we wanted to drop some old ballast things we don't want anymore or don't 19 00:01:43,195 --> 00:01:49,655 want to, can't maintain anymore, concepts that are broken or obsolete and generally 20 00:01:49,655 --> 00:01:51,295 not ready for the future. 21 00:01:52,715 --> 00:01:58,415 Then a lot of our stuff is built on Qt widgets, but there's more and more apps using QML. 22 00:01:59,075 --> 00:02:05,555 And we wanted to have a clean separation between API that is for either of those 23 00:02:05,555 --> 00:02:09,575 toolkits or or that is common between those two and can be shared. 24 00:02:10,095 --> 00:02:15,815 Then we wanted to improve the cross-platform support of our APIs and make it 25 00:02:15,815 --> 00:02:19,335 easier to build apps for Android, Windows, 26 00:02:19,675 --> 00:02:25,015 macOS, and so on, which sometimes means having a cleaner separation between 27 00:02:25,015 --> 00:02:27,175 an interface to something and the implementation. 28 00:02:30,055 --> 00:02:36,695 So how did the time continue? In late 2020, there was the first Qt 6 release, 29 00:02:37,015 --> 00:02:42,175 and naturally it didn't take very long for us to start building against that. 30 00:02:43,375 --> 00:02:48,195 In the initial phase, this was mostly done ad hoc without much coordination. 31 00:02:48,775 --> 00:02:57,635 And it was only in 2021 that we started doing things properly and introduced Qt 6-based CI builds, 32 00:02:57,635 --> 00:03:03,735 which then allowed us to actually start actively porting things while still 33 00:03:03,735 --> 00:03:05,635 keeping compatibility with Qt 5. 34 00:03:08,255 --> 00:03:17,955 Then fast forward a bit in January 2023 we started branching out KF6 which mostly 35 00:03:17,955 --> 00:03:24,095 meant creating a branch for Frameworks 5 for that to be continued in that branch 36 00:03:24,095 --> 00:03:27,515 and from then point on master was Qt 6 only. 37 00:03:27,815 --> 00:03:34,035 Soon after that Plasma and some other projects also started doing that but applications 38 00:03:34,035 --> 00:03:37,895 for the most part kept building against both at the same time. 39 00:03:38,815 --> 00:03:45,735 Then last year at Academy in Greece was the last talk I gave on this topic and 40 00:03:45,735 --> 00:03:51,555 back then I promised that was going to be the final talk about this topic which 41 00:03:51,555 --> 00:03:54,735 turned out to be a bit of a lie. So sorry about that. 42 00:03:55,815 --> 00:03:58,915 And I raised the question of, are we there yet? 43 00:04:06,368 --> 00:04:12,028 So then in November of that year, we had the first release of what we then call 44 00:04:12,028 --> 00:04:20,848 the mega release, because for logistical reasons, we decided to release Plasma 6.0, Framework 6.0, 45 00:04:21,468 --> 00:04:26,188 and the gear release at the same time, which was necessary because there's a 46 00:04:26,188 --> 00:04:30,108 lot of subtle interdependencies between all three of them. 47 00:04:30,968 --> 00:04:34,888 So releasing them together made things a lot easier to manage. 48 00:04:34,888 --> 00:04:37,868 In December, we had the betas. 49 00:04:38,188 --> 00:04:43,188 In January, we had the release candidates for them. 50 00:04:43,328 --> 00:04:49,588 And then in February 2024, at long last, almost five years about talking this 51 00:04:49,588 --> 00:04:52,268 initially, we had a mega release. 52 00:04:53,268 --> 00:04:54,828 Some applause would be nice. 53 00:05:00,148 --> 00:05:03,868 So how did our users receive this 54 00:05:03,868 --> 00:05:06,588 mega release in a 55 00:05:06,588 --> 00:05:11,868 lot of ways it was received very positively people liked it it was cool we had 56 00:05:11,868 --> 00:05:18,508 cool features and what particular what i particularly liked is that during these 57 00:05:18,508 --> 00:05:24,288 alpha beta and release candidate releases a lot of people were testing it that 58 00:05:24,428 --> 00:05:26,788 usually aren't testing or pre-releases. 59 00:05:27,108 --> 00:05:32,428 So there was a lot of interest and a lot of activity around that topic. 60 00:05:32,488 --> 00:05:35,268 And the community was really looking forward to it. 61 00:05:37,353 --> 00:05:43,773 But, of course, not everything was perfect. There were some bugs in the initial releases. 62 00:05:45,313 --> 00:05:50,973 Not as many as in previous transitions, but more than zero. 63 00:05:51,933 --> 00:05:58,953 We also made some design decisions that proved to be or were expected to be 64 00:05:58,953 --> 00:06:02,173 controversial, like dropping certain features, 65 00:06:02,593 --> 00:06:07,073 changing some defaults, or using Wayland by default. 66 00:06:07,073 --> 00:06:09,653 Which is something we did for Plasma 6.0. 67 00:06:10,953 --> 00:06:18,173 Then, unfortunately, a lot of distros had somewhat broken rollout of all of this. 68 00:06:19,353 --> 00:06:26,553 During the alpha and beta phases, we worked quite a bit on creating packaging 69 00:06:26,553 --> 00:06:30,753 recommendations and guidelines for shipping this release for distributions, 70 00:06:30,993 --> 00:06:33,873 because it really wasn't trivial. 71 00:06:34,193 --> 00:06:38,553 There were a lot of subtle things to watch out, and projects that needed to 72 00:06:38,553 --> 00:06:41,393 be built against both Qt 5 and Qt 6. 73 00:06:41,793 --> 00:06:46,333 So we wanted to make sure that this is as smooth as possible for distributions. 74 00:06:48,153 --> 00:06:50,633 Which mostly worked out, I think. 75 00:06:51,413 --> 00:06:57,993 There were two major problems. One of them is being the initial rollout of 6.0 76 00:06:57,993 --> 00:07:02,393 in Neon was very rough and had some quite major bugs, 77 00:07:02,393 --> 00:07:11,453 which mostly came down to very neon specific process problems and I'm not quite 78 00:07:11,453 --> 00:07:17,273 sure what to do about it but it was already discussed in a sort of post-mortem 79 00:07:17,273 --> 00:07:18,413 session on the neon side. 80 00:07:19,453 --> 00:07:27,113 And then the other big problem was that certain distributions Arch were deliberately 81 00:07:27,113 --> 00:07:29,893 ignoring some of our packaging recommendations. 82 00:07:31,213 --> 00:07:34,313 Which mostly meant not shipping 83 00:07:34,313 --> 00:07:41,673 various Qt 5 support integration packages by default which caused broken support 84 00:07:41,673 --> 00:07:47,553 for Qt 5 applications and we got a lot of bug reports and complaints and support 85 00:07:47,553 --> 00:07:51,633 requests about this but it was just Arch being Arch. 86 00:07:52,673 --> 00:07:55,733 And another thing that wasn't quite good is, 87 00:07:56,533 --> 00:08:02,513 a lot of the APIs in Plasma targeted towards third-party developers like Plasmoids, 88 00:08:02,673 --> 00:08:07,373 Quinn Effects, Quinn Script had breaking changes and we weren't always good 89 00:08:07,373 --> 00:08:08,653 about documenting these. 90 00:08:08,913 --> 00:08:13,673 So naturally a lot of people wanted to update their third-party content to Plasma 91 00:08:13,673 --> 00:08:20,613 6 but often didn't have any documentation on how to do that which caused understandable frustration. 92 00:08:25,266 --> 00:08:31,186 So, looking a bit on the API side, did we succeed in our design goals? 93 00:08:31,846 --> 00:08:38,306 On the positive side, we had a lot of simplifications in our frameworks and in Plasma, 94 00:08:38,466 --> 00:08:44,706 which meant that some things that previously would have been very hard to implement 95 00:08:44,706 --> 00:08:47,126 or fix were now easy to do. 96 00:08:47,806 --> 00:08:52,926 This is something mostly I or other people involved in this process noticed, 97 00:08:52,966 --> 00:08:56,686 because we know what we did and how it was before. 98 00:08:57,346 --> 00:09:01,866 But the thing is, a lot of people coming after us won't even notice that, 99 00:09:02,026 --> 00:09:06,806 because they just see, okay, it's easy, but they don't know all of the work 100 00:09:06,806 --> 00:09:08,566 that went into that being easy. 101 00:09:10,246 --> 00:09:17,406 On the negative side, we had a few API design decisions that turned out to be 102 00:09:17,406 --> 00:09:24,086 problematic in some ways, because they weren't obvious to use and hard to misuse, 103 00:09:24,266 --> 00:09:28,346 which caused some bugs, more than I would have liked. 104 00:09:28,846 --> 00:09:34,586 And some of these API decisions were done by myself, so I have no one to blame but myself. 105 00:09:36,746 --> 00:09:45,406 Then during the initial phase of deprecating things and then introducing a replacement 106 00:09:45,406 --> 00:09:49,266 for something, then deprecating it, then putting everything away, 107 00:09:49,806 --> 00:09:56,186 I think we did a quite good job of documenting all of this in like deprecation documentation. 108 00:09:57,166 --> 00:10:00,306 So people generally knew how to port away from these. 109 00:10:01,146 --> 00:10:08,006 But there was a phase where we stopped doing that because master was KF6 only. 110 00:10:08,246 --> 00:10:17,746 And we were in a phase where we allowed ourselves to break APIs with auto-proper deprecation process, 111 00:10:18,126 --> 00:10:23,726 which made a lot of things very easy and convenient to do for us that otherwise 112 00:10:23,726 --> 00:10:29,606 wouldn't have been possible, but we didn't always do a good job of documenting this to, 113 00:10:30,366 --> 00:10:31,866 people porting after us. 114 00:10:32,366 --> 00:10:35,626 We had a policy of if you drop something, 115 00:10:35,886 --> 00:10:41,146 you need to port all of the users that are currently on KF6, which worked okay, 116 00:10:41,386 --> 00:10:44,766 but if someone didn't port 117 00:10:44,766 --> 00:10:49,086 at that time but is porting now they sometimes run into problems with hey how 118 00:10:49,086 --> 00:10:55,766 do i actually port this and we don't have any documentation for it and the documentation 119 00:10:55,766 --> 00:11:01,386 for the general reporting process was mostly a bunch of academy talks from me 120 00:11:01,386 --> 00:11:04,386 but not much in written form. 121 00:11:19,609 --> 00:11:24,069 But try finding that commit three years later when you're forwarding something. 122 00:11:26,649 --> 00:11:29,109 It's a lot of work that shouldn't be necessary. 123 00:11:32,329 --> 00:11:38,469 Then during the initial KF6 print, we created a very large workboard with a 124 00:11:38,469 --> 00:11:41,589 couple of hundred tasks on it of things that we want to do. 125 00:11:42,729 --> 00:11:45,929 We didn't get to do all of them. some 126 00:11:45,929 --> 00:11:48,829 of them because we decided okay this is not worth doing 127 00:11:48,829 --> 00:11:52,049 actually some of them were decided 128 00:11:52,049 --> 00:11:55,569 okay we don't actually need to do this now we 129 00:11:55,569 --> 00:11:58,649 can always do it later and we don't need to break api for 130 00:11:58,649 --> 00:12:01,409 it but for some of them we just missed the window 131 00:12:01,409 --> 00:12:04,309 of doing them because too many other things to 132 00:12:04,309 --> 00:12:09,549 do and the whole process already took enough time and we didn't want to definitely 133 00:12:09,549 --> 00:12:15,269 delay it until everything is perfect so at some point we had to ship because 134 00:12:15,269 --> 00:12:22,309 it got unsustainable to just keep iterating on on unstable master and eventually 135 00:12:22,309 --> 00:12:23,889 we just needed to ship something, 136 00:12:24,809 --> 00:12:32,149 and similarly we had a lot of to do kf6 comments throughout our code not all 137 00:12:32,149 --> 00:12:37,789 of them did get addressed, so they're now in good company with some of the to-do KF5 comments. 138 00:12:39,729 --> 00:12:44,109 And somewhat recently, we introduced the first to-do KF7 comment. 139 00:12:45,969 --> 00:12:51,409 And some of the API changes in particular, that's something we noticed in Kirigami 140 00:12:51,409 --> 00:12:58,169 came quite late in the process, which wasn't great because then we had to do 141 00:12:58,169 --> 00:13:00,149 a lot of last-minute porting. 142 00:13:01,029 --> 00:13:08,069 But that was also complicated by the fact that we had a pretty good strategy for evolving C++ API. 143 00:13:08,809 --> 00:13:12,969 Introduce a replacement, port all of the users, deprecate the old thing, 144 00:13:13,069 --> 00:13:15,329 and then at branching, remove the thing. 145 00:13:15,509 --> 00:13:18,249 Worked out quite well. For QML, that was 146 00:13:18,249 --> 00:13:26,729 a lot harder because all of the deprecation warning markup and if-devs and compatibility 147 00:13:26,729 --> 00:13:28,989 builds don't really work with 148 00:13:28,989 --> 00:13:35,509 QML and you don't have a good way to do version-dependent code in QML. 149 00:13:35,849 --> 00:13:43,769 So it was very hard and basically next to impossible to have QML apps work against both Qt 5 and Qt 6. 150 00:13:44,509 --> 00:13:47,369 Which is a fact that I lamented quite a lot. 151 00:13:47,469 --> 00:13:51,949 So this week at the Contributor Summit, we actually had a very good conversation 152 00:13:51,949 --> 00:13:59,969 with some of the QML people about how they can or we can support this use case better in the future, 153 00:14:00,089 --> 00:14:06,369 which is going to stay relevant even when most of the transition is done by now. 154 00:14:10,447 --> 00:14:17,127 Talking about challenges, we had a few. First and foremost, while this transition 155 00:14:17,127 --> 00:14:22,047 was nowhere near as painful as previous transitions, so I've heard I haven't 156 00:14:22,047 --> 00:14:23,707 been part of any of the previous ones, 157 00:14:24,707 --> 00:14:28,947 it was still a lot of work because we have a lot of code. 158 00:14:29,467 --> 00:14:34,567 When I'm doing presentations for different audiences than just KDE, 159 00:14:34,767 --> 00:14:41,327 I like to introduce ourselves with, we have about 15 million lines of C++ in QML code. That's a lot. 160 00:14:42,767 --> 00:14:49,947 And even if there are only small changes needed, if you multiply that by 15 161 00:14:49,947 --> 00:14:51,947 million lines of code, that's still a lot. 162 00:14:52,187 --> 00:14:54,287 And sometimes you need to touch 163 00:14:54,287 --> 00:14:58,887 code that you really don't want to touch because nobody understands it, 164 00:14:59,507 --> 00:15:03,567 but you need to touch it anyway because it uses something that doesn't exist 165 00:15:03,567 --> 00:15:10,127 anymore or you want to get rid of a certain API or any reason. 166 00:15:10,307 --> 00:15:15,327 And sometimes that took a bit of a leap of faith and a lot of blood, 167 00:15:15,367 --> 00:15:19,507 sweat and tears to make sure it keeps working. 168 00:15:21,067 --> 00:15:26,327 Then we also depend on some third-party modules that are also based on Qt. 169 00:15:26,387 --> 00:15:32,887 So we also needed Qt 6 builds of them, which in most cases wasn't much of a 170 00:15:32,887 --> 00:15:36,167 problem because upstreams were receptive about, 171 00:15:37,527 --> 00:15:41,947 either did it themselves or were receptive about us porting them to Qt 6. 172 00:15:42,407 --> 00:15:51,567 In some cases, it took a bit longer than necessary for them to accept and release our changes. 173 00:15:53,147 --> 00:15:59,167 We still have some libraries in the K account stack that aren't released against 174 00:15:59,167 --> 00:16:05,187 Qt 6 yet, but basically distros now ship our sort of fork of it. 175 00:16:07,908 --> 00:16:11,048 But it worked out okay enough in the end. 176 00:16:11,728 --> 00:16:16,528 Then when Qt 6.0 was released, there was a bit of functionality missing that 177 00:16:16,528 --> 00:16:22,228 we were previously using that sometimes was clear, okay, this is not coming 178 00:16:22,228 --> 00:16:23,968 back because it was deprecated before. 179 00:16:24,488 --> 00:16:30,568 And sometimes we had to lobby them into adding back some of the APIs that we needed. 180 00:16:30,768 --> 00:16:35,988 And by around 6.5, we were mostly complete on that front. 181 00:16:35,988 --> 00:16:39,088 And the first release of 182 00:16:39,088 --> 00:16:42,488 the first mega release was against Qt 6.6 183 00:16:42,488 --> 00:16:45,628 and to keep 184 00:16:45,628 --> 00:16:49,288 supporting Qt 5 we had to create the 185 00:16:49,288 --> 00:16:57,248 KDE patch collection because Qt 5 was closed for contributions and the LTS release 186 00:16:57,248 --> 00:17:01,908 was commercial only and open source was delayed by a year so we needed a way 187 00:17:01,908 --> 00:17:08,428 for us to have patches for Qt for bug fixes that wasn't upstream Qt, 188 00:17:08,528 --> 00:17:11,668 which worked out okay enough, 189 00:17:11,828 --> 00:17:16,528 but it was a hassle that I would have liked to avoid. 190 00:17:20,568 --> 00:17:26,008 So with us being there yet, the obvious question is, what comes next? 191 00:17:27,148 --> 00:17:33,908 And before we get into that, we need to ask ourselves, are we actually really there yet? 192 00:17:34,708 --> 00:17:39,228 While it's true that we have had the mega release and a lot of our applications 193 00:17:39,228 --> 00:17:46,748 and Plasma built against Qt 6, we still have some of them that built and released against Qt 5. 194 00:17:49,168 --> 00:17:53,988 That's a problem because, well, here it says Qt 5 is out of support. 195 00:17:53,988 --> 00:17:59,268 Today I learned from Volker Hilsheimer that this isn't actually quite true because 196 00:17:59,268 --> 00:18:05,428 there's still a small amount of things going on there and getting released. 197 00:18:05,848 --> 00:18:09,788 But for all intents and purposes, consider Qt 5 dead. 198 00:18:11,928 --> 00:18:17,628 And Qt 6 in many ways is just better, even if your application isn't actually 199 00:18:17,628 --> 00:18:22,848 using any of the new API. Some of the improvements under the hood makes the 200 00:18:22,848 --> 00:18:25,288 experience of using them just a lot better. 201 00:18:26,028 --> 00:18:31,328 This is particularly the case of Wayland support, which improved a lot in Qt 202 00:18:31,328 --> 00:18:37,108 6 and fixed some long-standing problems there, which is very important given 203 00:18:37,108 --> 00:18:38,568 that Wayland is the default now. 204 00:18:40,188 --> 00:18:45,968 Then moving on to KO5, it's still technically officially maintained and released, 205 00:18:46,068 --> 00:18:49,108 but in practice not a lot is happening there. 206 00:18:49,588 --> 00:18:54,568 So, while it's still possible to get bug fixes in there, very few people actually 207 00:18:54,568 --> 00:19:00,888 do it, so it doesn't receive much improvement, while KF6 is very actively developed. 208 00:19:03,164 --> 00:19:11,284 And it pains me to admit it, but support for running Qt 5 applications in an 209 00:19:11,284 --> 00:19:15,704 otherwise Plasma 6 session is also subtly broken in some cases. 210 00:19:16,484 --> 00:19:23,404 For example, anything that relies on plugins needs those plugins to be built against Qt 5 and Qt 6. 211 00:19:23,884 --> 00:19:29,304 And distros either don't ship them or we don't even provide them properly upstream. 212 00:19:29,564 --> 00:19:34,404 So there's a lot of subtly broken things here and there. that just work fine 213 00:19:34,404 --> 00:19:36,364 in a completely KF6 session. 214 00:19:37,984 --> 00:19:47,284 All of this raises the obvious question, do we or can we or when can we drop 215 00:19:47,284 --> 00:19:50,484 support for Qt 5 in our CI infrastructure, 216 00:19:51,044 --> 00:19:53,564 in our build systems and so on and so forth? 217 00:19:54,804 --> 00:20:01,984 I do not have the answer to that. A large factor we need to take into account is 218 00:20:02,164 --> 00:20:10,444 that there are still distributions out there that ship Plasma 527 and KF5 and KF5-based apps. 219 00:20:10,844 --> 00:20:16,784 This includes also this year's Ubuntu LTS releases, which for unfortunate but 220 00:20:16,784 --> 00:20:20,004 understandable reasons doesn't ship Plasma 6 yet. 221 00:20:20,184 --> 00:20:24,724 And that will be supported by Ubuntu officially for the next two years. 222 00:20:25,844 --> 00:20:29,104 I'm not sure whether we can afford to ignore that. 223 00:20:30,824 --> 00:20:38,304 So that's perhaps something to discuss this week or the next weeks, months and year. 224 00:20:41,064 --> 00:20:41,904 We could. 225 00:20:45,244 --> 00:20:48,004 Okay, what's next for our software platform? 226 00:20:50,064 --> 00:20:53,844 So to answer the question of what is next for the KDE community, 227 00:20:54,124 --> 00:21:00,004 we just elected some new goals, which is generally the best indication of what's 228 00:21:00,004 --> 00:21:01,204 next for us as a community. 229 00:21:02,084 --> 00:21:09,164 As it stands, my personal goal proposal got selected, which is all about improving 230 00:21:09,164 --> 00:21:10,844 the application development experience. 231 00:21:11,604 --> 00:21:17,044 And naturally, there is a huge overlap between that and all of the work we've 232 00:21:17,044 --> 00:21:24,904 been doing on modernizing and polishing and porting to Vue 6 our frameworks and software platform. 233 00:21:26,985 --> 00:21:32,225 And generally, we should just continue what we've been doing in the initial 234 00:21:32,225 --> 00:21:38,445 phase of the Qt 6 port, which is just finding APIs that are problematic and we don't like anymore, 235 00:21:39,285 --> 00:21:42,185 introduce replacements, and deprecate the old thing. 236 00:21:42,825 --> 00:21:47,665 It will probably be a while until we can drop them, but at least having them 237 00:21:47,665 --> 00:21:51,785 deprecated means it will be dropped eventually, and it tells people, 238 00:21:51,925 --> 00:21:54,445 this isn't good API, don't use it. 239 00:21:55,525 --> 00:21:58,865 Then a topic that keeps appearing again 240 00:21:58,865 --> 00:22:05,985 and again is Wayland we made Wayland the default which was a somewhat controversial 241 00:22:05,985 --> 00:22:12,205 decision but as far as I'm concerned it was the right one and according to our 242 00:22:12,205 --> 00:22:18,845 user feedback statistics about 80% of Plasma 6 users are using Wayland right now. 243 00:22:20,985 --> 00:22:27,005 Wayland still isn't perfect effect and we as a community need to come together 244 00:22:27,005 --> 00:22:28,565 and address those problems. 245 00:22:29,185 --> 00:22:34,585 Historically it has been mostly the case that most of the work on improving 246 00:22:34,585 --> 00:22:41,805 the Wayland experience have been driven by a few plasma and quinn maintainers but this doesn't scale. 247 00:22:42,285 --> 00:22:48,685 So most of the big issues in Wayland are addressed by now or in the process 248 00:22:48,685 --> 00:22:54,545 of getting addressed but there's still a very long tail of small quality-of-life 249 00:22:54,545 --> 00:22:56,885 annoyances and things that are subtly broken. 250 00:22:57,125 --> 00:23:01,805 And it can't be the responsibility of David Edmondson and Flood alone to fix 251 00:23:01,805 --> 00:23:02,905 all of the things in Wayland. 252 00:23:03,205 --> 00:23:08,685 And we as application developers need to watch out for things that we can do 253 00:23:08,685 --> 00:23:13,185 in our application code to fix those little Wayland annoyances. 254 00:23:13,705 --> 00:23:18,125 Because in a lot of cases, it's the application that's wrong, 255 00:23:18,225 --> 00:23:19,765 not the toolkit or the compositor. 256 00:23:21,365 --> 00:23:24,285 Then earlier today david was 257 00:23:24,285 --> 00:23:27,865 talking about flat pack snaps immutable 258 00:23:27,865 --> 00:23:30,945 distros and sandboxing which according to 259 00:23:30,945 --> 00:23:35,645 him and i very much value is his opinion is one 260 00:23:35,645 --> 00:23:38,545 of the things that we should be watching out 261 00:23:38,545 --> 00:23:41,945 for and focusing on for the foreseeable future which 262 00:23:41,945 --> 00:23:46,165 is something i can very much agree with and as 263 00:23:46,165 --> 00:23:48,925 David mentioned in his talk there's quite a 264 00:23:48,925 --> 00:23:53,725 few things to be addressed there and there's 265 00:23:53,725 --> 00:23:59,225 the seemingly never-ending debate about the merits of Qt widgets versus QML 266 00:23:59,225 --> 00:24:07,525 where I don't see either of them going away anytime soon but the trend clearly 267 00:24:07,525 --> 00:24:11,885 indicates that the favors are tilting towards QML. 268 00:24:12,865 --> 00:24:20,645 And we need to find some sort of answer to where do we want to position ourselves 269 00:24:20,645 --> 00:24:24,245 in that regard with our software platform. 270 00:24:28,083 --> 00:24:34,703 Then we just completed one transition, mostly anyway. What about the next one? 271 00:24:36,083 --> 00:24:40,743 Historically, it has been the case that these major version transitions have 272 00:24:40,743 --> 00:24:42,743 been driven by Qt releases. 273 00:24:44,523 --> 00:24:52,243 And this one has been no exception. But it also has been multiple transitions in a trench code. 274 00:24:52,683 --> 00:24:55,143 We had an API break in Qt. 275 00:24:55,783 --> 00:24:57,423 We had an API break in frameworks. 276 00:24:58,083 --> 00:25:04,803 We had an API break in Plasma. We had a sort of user experience break in the 277 00:25:04,803 --> 00:25:08,383 sense that we dropped some things, we changed some defaults, 278 00:25:08,383 --> 00:25:12,843 we made Wayland the default, we made some design changes. 279 00:25:12,943 --> 00:25:15,883 And all of that, or not all of that, 280 00:25:15,923 --> 00:25:22,343 is something that would be neatly justifiable in just a minor release. 281 00:25:23,343 --> 00:25:31,183 So having a 0.0 release afforded us some leeway to do bigger changes that otherwise 282 00:25:31,183 --> 00:25:32,643 would have been more controversial. 283 00:25:33,663 --> 00:25:40,183 And we did the valent by default thing. All of those were done together at the same time. 284 00:25:40,263 --> 00:25:48,043 There were good reasons for doing it that way, but it doesn't necessarily have to be that way always. 285 00:25:49,763 --> 00:25:56,223 Here's a few questions I want to ask, and I don't really expect any answers to them right now. 286 00:25:56,763 --> 00:26:01,403 I also don't have anything concrete to propose. I just want to give you some 287 00:26:01,403 --> 00:26:07,483 food for your brain to think about some things for the foreseeable future. 288 00:26:08,183 --> 00:26:12,823 First of all, will there be a Qt 7? I asked the Qt people. 289 00:26:15,983 --> 00:26:17,763 Okay, that's surprisingly specific. 290 00:26:20,443 --> 00:26:22,863 Is that just extrapolating or? 291 00:26:25,883 --> 00:26:26,063 Thank you. 292 00:26:38,139 --> 00:26:40,959 Right so the big 293 00:26:40,959 --> 00:26:43,879 thing is nobody knows what's gonna 294 00:26:43,879 --> 00:26:46,879 happen there may be maybe that 295 00:26:46,879 --> 00:26:50,719 alan is perfectly on point with his extrapolation it 296 00:26:50,719 --> 00:26:59,499 could be that five years from now we are all writing electron apps so we don't 297 00:26:59,499 --> 00:27:05,699 really know we should prepare for the future where alan is right and And we 298 00:27:05,699 --> 00:27:08,959 have a Qt 7 release somewhat soon. 299 00:27:10,299 --> 00:27:15,959 But it doesn't have to be that way. Then something we noticed by doing all of 300 00:27:15,959 --> 00:27:19,719 this work with breaking stuff, breaking stuff is actually very fun. 301 00:27:20,099 --> 00:27:24,539 Because as I mentioned, things that were once hard are now easy. 302 00:27:25,439 --> 00:27:31,519 And doing some things becomes a lot more easy or even feasible in the first 303 00:27:31,519 --> 00:27:35,779 place by making breaking changes, which raises the question, 304 00:27:36,039 --> 00:27:38,079 should we do that more often? 305 00:27:38,479 --> 00:27:43,399 Because historically our compatibility cycles in Qt and in frameworks have been 306 00:27:43,399 --> 00:27:47,679 very long, close to a decade in a lot of cases. 307 00:27:48,799 --> 00:27:53,579 It doesn't have to be that way. I'm not saying we should abandon API stability altogether, 308 00:27:53,939 --> 00:27:59,139 but we could meet somewhere in in the middle and have, for example, 309 00:27:59,139 --> 00:28:05,079 a API break once a year or every two years. It doesn't have to be a decade. 310 00:28:06,919 --> 00:28:11,079 Also, something Qt and frameworks provide is ABI stability. 311 00:28:13,799 --> 00:28:22,399 Which I want to raise the question of how valuable is this to the people that 312 00:28:22,399 --> 00:28:23,739 are delivering our software, 313 00:28:23,839 --> 00:28:30,619 which is mostly Linux distributions or ourself via some sort of bundled format, 314 00:28:30,699 --> 00:28:31,939 whether that's Flatpak, 315 00:28:32,119 --> 00:28:34,459 Windows installers, Android APKs. 316 00:28:34,459 --> 00:28:38,579 Is do we need API stability for this? 317 00:28:39,179 --> 00:28:45,759 And if not, what kind of nicer things would this allow us to have? 318 00:28:45,979 --> 00:28:51,799 And is it worth the cost of changing the stability guarantee? 319 00:28:53,139 --> 00:29:01,419 And another thing David mentioned earlier is how does Flatpak and Snaps and 320 00:29:01,419 --> 00:29:08,119 immutable distros change all of the assumptions that we previously had and that 321 00:29:08,119 --> 00:29:10,119 influenced the way of us doing things. 322 00:29:10,439 --> 00:29:17,379 For example, we have a lot of functionality and integration points that basically 323 00:29:17,379 --> 00:29:23,999 assume we have a Linux distribution with one version of Qt installed and everything 324 00:29:23,999 --> 00:29:26,479 is built against that particular Qt. 325 00:29:27,099 --> 00:29:32,959 Basically, all of the plugin mechanisms rely on this fact. This already broke 326 00:29:32,959 --> 00:29:37,899 when we introduced Qt 6 in addition to Qt 5, which caused us a lot of headache. 327 00:29:38,839 --> 00:29:45,199 Now that we have containerized formats like Flatpak that do ship their own version 328 00:29:45,199 --> 00:29:50,259 of Qt, a lot of the plugin integration doesn't work anymore. 329 00:29:50,939 --> 00:29:54,619 And another aspect of Flatpak and all of the others, 330 00:29:54,779 --> 00:30:00,859 I don't want to single out Flatpak here, is that they ship their own version 331 00:30:00,859 --> 00:30:06,919 of Qt so we can actually very easily have different versions of Qt or frameworks 332 00:30:06,919 --> 00:30:10,019 or any toolkit installed in any given system, 333 00:30:10,219 --> 00:30:16,879 which means that breaking APIs in there actually becomes a lot more affordable 334 00:30:16,879 --> 00:30:24,259 and might influence on how we see those stability guarantees for our libraries. 335 00:30:25,399 --> 00:30:29,299 But as I said, I don't have any concrete proposals here. 336 00:30:29,399 --> 00:30:33,879 I'm not advocating for breaking all of our stability guarantees tomorrow. 337 00:30:35,219 --> 00:30:40,639 But I'm looking forward to having your thoughts on all of this and where to 338 00:30:40,639 --> 00:30:43,879 go next with our software platform. So, thank you. 339 00:30:54,939 --> 00:31:00,759 So, thank you, Nicholas, for your presentation. And, yeah, do you have questions? 340 00:31:09,863 --> 00:31:13,323 Okay um yeah uh 341 00:31:13,323 --> 00:31:17,563 you mentioned that the sorry um 342 00:31:17,563 --> 00:31:20,923 the documentation changes 343 00:31:20,923 --> 00:31:23,963 and the portal uh the missing documentation for for 344 00:31:23,963 --> 00:31:27,463 porting um personally it 345 00:31:27,463 --> 00:31:35,043 it would have been easier for me if at least the kf5 documentation would still 346 00:31:35,043 --> 00:31:41,403 be available somewhere because kd lips for documentation is still online but 347 00:31:41,403 --> 00:31:46,983 kf5 is not so do you have any plans to maybe add that, 348 00:31:48,363 --> 00:31:55,043 okay there's two answers to this one of them is it should be fairly easy for 349 00:31:55,043 --> 00:32:01,183 somebody like ben to add the kf5 version as a read-only copy to the archive, 350 00:32:02,783 --> 00:32:09,083 The second answer to that is, we did consider, can we provide both of them at 351 00:32:09,083 --> 00:32:13,123 the same time, which turned out to be very hard given our current documentation infrastructure, 352 00:32:13,643 --> 00:32:19,763 which is why we didn't do it, because nobody felt motivated enough to put in all the effort. 353 00:32:21,663 --> 00:32:29,643 What I am currently working right now is porting all of our documentation from Doxygen to QDoc, 354 00:32:29,643 --> 00:32:34,283 and this would actually make it a lot easier and it's something that I'm actively 355 00:32:34,283 --> 00:32:40,343 looking out for to provide multiple versions of documentation in the future. 356 00:32:40,883 --> 00:32:47,503 Whether we are going to go through the effort of converting the existing KF5 357 00:32:47,503 --> 00:32:52,503 API mark up to the new format to allow that, I don't know. 358 00:32:53,363 --> 00:32:57,423 It would take someone very motivated to do that so I'm not going to promise 359 00:32:57,423 --> 00:33:04,103 that. but at least looking to future transitions this should become a lot more feasible. 360 00:33:07,583 --> 00:33:11,403 Any further questions? I think over there there is a question, 361 00:33:14,095 --> 00:33:18,115 So before my question, I have a couple of comments, one of which is that your 362 00:33:18,115 --> 00:33:23,655 remark that Arch was being Arch could be said to have been a rather Arch comment. 363 00:33:26,335 --> 00:33:32,255 I just want to comfort you a little on one point, which is that you said you missed some to-dos. 364 00:33:32,655 --> 00:33:35,635 In the rush to the Qt 6 release, 365 00:33:36,435 --> 00:33:41,235 we had a mad rush to deal with a whole lot of, 366 00:33:42,015 --> 00:33:44,955 hash hash hash qt6 to do 367 00:33:44,955 --> 00:33:47,695 comments and we did get 368 00:33:47,695 --> 00:33:50,435 quite a lot of them but um some of them had to 369 00:33:50,435 --> 00:33:55,395 be turned into qt7 ones so you're not alone this this is just how big releases 370 00:33:55,395 --> 00:34:02,475 go um and um we have adopted a policy which you might want to think about for 371 00:34:02,475 --> 00:34:07,355 future reference which is we now as far as possible if it is something to change 372 00:34:07,355 --> 00:34:09,395 at the next major release we actually say. 373 00:34:11,835 --> 00:34:15,335 Hash if qt major 374 00:34:15,335 --> 00:34:18,955 version is less than sorry it's 375 00:34:18,955 --> 00:34:21,895 greater than equal to seven or we're in a bootstrap 376 00:34:21,895 --> 00:34:25,435 build do it the future way hash else 377 00:34:25,435 --> 00:34:28,235 do it the modern do it the current the old way the way 378 00:34:28,235 --> 00:34:31,115 we're still doing it so that when we hit qt 379 00:34:31,115 --> 00:34:34,715 7 we will automatically make the transition the all 380 00:34:34,715 --> 00:34:38,135 bootstrap similar in some cases the all 381 00:34:38,135 --> 00:34:40,915 bootstrap is there so that we will actually see most of 382 00:34:40,915 --> 00:34:44,215 the breakages before we get there well we 383 00:34:44,215 --> 00:34:47,295 don't have a bootstrap like that so that's not 384 00:34:47,295 --> 00:34:51,195 going to be as practical but yeah you do have a good point it's something we 385 00:34:51,195 --> 00:34:56,235 could have potentially used a lot more finally to my question you mentioned 386 00:34:56,235 --> 00:35:01,915 touching some scary code did you record all the places you found scary code 387 00:35:01,915 --> 00:35:06,175 in a big list of come back with the flamethrower? 388 00:35:07,775 --> 00:35:09,055 Not explicitly. 389 00:35:12,955 --> 00:35:19,795 This. This was actually a major reason of why we went through the trouble of 390 00:35:19,795 --> 00:35:24,235 killing a lot of things in frameworks because it was scary code. 391 00:35:26,455 --> 00:35:29,695 And actually the mere thing of 392 00:35:29,695 --> 00:35:32,755 going through all of the code and looking for things 393 00:35:32,755 --> 00:35:37,855 that we could potentially do without was at least for me a very valuable lesson 394 00:35:37,855 --> 00:35:43,095 in getting to know our code base better because now I have a very good overview 395 00:35:43,095 --> 00:35:48,535 of a lot of the frameworks code that I didn't used to have even if not in all 396 00:35:48,535 --> 00:35:51,195 cases this resulted in actual changes being made. 397 00:35:52,375 --> 00:36:00,795 But the list is still somewhere there might be a good idea to formalize that ... 398 00:36:11,732 --> 00:36:14,752 So actually we're talking a 399 00:36:14,752 --> 00:36:18,632 lot about kde in itself but also 400 00:36:18,632 --> 00:36:26,792 there are external applications which use frameworks and cute and actually from 401 00:36:26,792 --> 00:36:35,012 debian there's a lot of cute five stuff still available which isn't ported yet. 402 00:36:35,332 --> 00:36:41,672 So thinking about when to break API again, it will also, 403 00:36:42,752 --> 00:36:50,932 happen that external applications get broken again and distros need to work around. 404 00:36:51,312 --> 00:36:58,532 So this is really also something to think about that things are used externally. 405 00:37:00,732 --> 00:37:09,532 Yes that is a very good point and if we decide that having a more relaxed approach 406 00:37:09,532 --> 00:37:11,932 about api stability is the way 407 00:37:11,932 --> 00:37:18,992 to go we probably want some sort of formal communication channel for that, 408 00:37:20,132 --> 00:37:27,632 and somewhat related to that you you bring up a good point with third-party qt5 applications 409 00:37:27,972 --> 00:37:35,912 which is we have quite a few things that are only there to hook into Qt and 410 00:37:35,912 --> 00:37:42,432 provide some integration bits like plasma integration or breeze and oxygen styles and so on. 411 00:37:42,852 --> 00:37:48,372 So the decision of when to retire the Qt 5 versions of them is not only influenced 412 00:37:48,372 --> 00:37:53,452 by how many of our applications are ported but also how many third-party Qt 413 00:37:53,452 --> 00:37:57,372 5 applications are still out there and they're implicitly using these things. 414 00:37:59,952 --> 00:38:04,752 Okay. So, yeah. Thanks for the presentation and questions. 415 00:38:04,892 --> 00:38:08,652 And we are now running out of time.