Qt 公司 CTO 兼 Qt 项目的首席维护者（Chief Maintainer）Lars Knoll 在 Akademy 2019 会议上宣布 Qt 6 计划于 2020 年 11 月发布。在确认这一消息后，KDE 项目的开发者就关于下一代框架所采用的 工具 包更新进行了早期讨论。
KDE 项目开发者 Volker Krause 和大家分享了一些他对 KDE 6 的想法，以及团队讨论的内容。
Volker 表示 KDE Frameworks 6 会在 Qt 6.0 推出的两年内，或至少一年后发布。因为 Qt 6.0 已被确定时，KDE Frameworks 6 的实际开发工作大概会从 2020 年下半年开始。而且在不久的将来，在开发的某个阶段中，他们有可能会采用敏捷开发中的“较短工作周期”（Scrum Sprint）方式。
虽然 Qt 团队一直表示会将尽最大努力保持 Qt 5 和 Qt 6 之间的兼容性，但新的主要版本肯定也会触发 KDE 的更改。为此，KDE 团队也会提前做好准备。
KDE 团队会将代码从已弃用的 Qt 方法中移植出去，以便在禁用弃用方法的情况下从 Qt 5.14 开始完全构建。这部分的主要工作是关于删除已弃用的模块、类或方法的使用，这些模块、类或方法预期将随 Qt 6 或 KF6 的发布而一起消失。
另外，还有一些依赖 Qt 6 或需要执行实际 ABI 中断的任务，不过这些任务在目前尚属少数，而且当然需要等到开发的那个阶段才开始（大概是在 2020 年下半年）。
除了计划要在 KF6 中实现的目标外，对如何过渡到 KF6 的计划也同样重要。Lars 提出了 Qt 采用的方法，但 KDE 的情况在某些方面与 Qt 不同。KDE 并不是主要生产框架，而是在这些框架的基础上构建产品（Plasma 和数百个应用程序），这使我们能够为允许更改或删除的内容定义其他标准。
KDE 团队的想法是定义一组阻止重大更改的模块。也就是说，在进行重大更改之前，需要对这些模块进行调整（或者至少需要微调）。例如避免类似“ KHTML 已被弃用，请移植到 QWebEngine”之类的事情。虽然两者都可以以某种方式渲染 HTML 文档，但这就是不同之处，API 和 API 的功能有很大的不同，并且并非所有的用例都可以轻松映射（如果有的话）。更重要的是，解决这一问题的负担不应仅由应用程序维护人员承担，因为这将导致许多事情在未来几年内仍留在 Qt5/KF5 上。
最后，KDE 团队已经开始了一些比较底层的工作，例如由 Friedrich 牵头负责的基础结构研究工作，以在编译时禁用 KDE Framework 中不推荐使用的方法，这个做法与 Qt 类似。
Andreas 已将 Step、Kalzium 和 Parley 从 KHTML 移植出去，而 Sune 已开始为 KHelpCenter 做同样的事情。在 Konqueror 中，他们还摆脱了 KHTML 的大量使用，现在仅保留 about 页面还使用 KHTML。
猜你喜欢: