Company CTO and chief maintainer of Qt Qt project (Chief Maintainer) Lars Knoll at Akademy 2019 conference announced Qt 6 scheduled for release in November 2020. After confirming the news, KDE project developers have on the next generation of tools used in the framework of package updates were discussed earlier.
KDE project developers Volker Krause and we share some of the contents of his discussion of the idea of KDE 6, as well as the team.
Volker represents the KDE Frameworks 6 in Qt 6.0 will launch two years, or at least one year after the release. Because Qt 6.0 has been determined, KDE Frameworks actual development work will start about 6 from the second half of 2020. And in the near future, at a certain stage of development, they likely will adopt agile development, "short duty cycle" (Scrum Sprint) mode.
Although Qt team has always said would do its utmost to maintain compatibility between 6 Qt 5 and Qt, but the new version will certainly trigger a major change of KDE. To this end, KDE team will prepare in advance.
Built entirely from the KDE start Qt 5.14 in the case team will be porting code from Qt method has been deprecated out in order to disable deprecated methods. The main part of this work is to use about deleting deprecated modules, classes or methods, these modules, class or method is expected to be with the release of Qt 6 or KF6 disappear together.
In addition, some rely on Qt 6 or need to perform the actual ABI interrupted task, but these tasks at present is still a minority, but of course, need to wait until that stage of development started (probably in the second half of 2020).
In addition to the planned objectives to be achieved in KF6, equally important how the transition to KF6 plan. Lars proposed a method of using Qt, KDE but the situation is different in some respects Qt. KDE is not a major production framework, but building products (Plasma and hundreds of applications) on the basis of the framework, which allows us to change or delete the contents of the definition to allow other standards.
KDE team idea is to define a set of modules to prevent significant changes . That is, before making major changes need to be adjusted (or at least require fine-tuning) of these modules. For example, to avoid similar "KHTML has been deprecated, please migrate to QWebEngine" sort of thing. Although both can render an HTML document in some way, but this is different from the function, API and API's are very different, and not all use cases can be easily mapped (if any). More importantly, the burden of solving this problem should not be borne only by the application maintenance personnel, as this will lead to many things remain on Qt5 / KF5 in the coming years.
Finally, KDE team has started a number of relatively low-level work, such as the responsibility of the Friedrich-led research infrastructure, to disable KDE Framework at compile time is not recommended methods used, and this approach is similar to Qt.
Andreas has Step, Kalzium and Parley from KHTML transplant out, and Sune KHelpCenter has begun to do the same thing. In Konqueror, they also get rid of a lot of use KHTML, now only retains about page also uses KHTML.