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。
[admin
]
來源：OsChina
連結：https://www.oschina.net/news/110625/kf6-road-to-kde-frameworks6
KDE Frameworks 6 將基於 Qt 6 開發，最早在 Qt 6 發布一年後推出已經有221次圍觀
