IT资讯 KDE Frameworks 6 将基于 Qt 6 开发,最早在 Qt 6 发布一年后推出

cecil · 2019-10-17 10:00:05 · 热度: 11

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。

猜你喜欢:
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册