原文:Technical vision for Qt 6 原作者: 翻译校对:Richard Lin 自从七年前Qt 5发布后,我们的世界发生了很多变化,现在是时候展望和规划下一个新的主版本了。这篇博文捕捉了几个将要在Qt 6中亮相的关键点。 Qt 6将是我们Qt 5系列的延续, 因此不会对用户造成干扰。但是这个新的版本将拥有更高的灵活性来实现新的特性和功能,和目前的Qt 5系列相比,它能更好地支持当下和未来的需求。正如下面即将描述的一样,Qt 6将致力于实现与Qt 5很大程度上的兼容。Qt 5的新版本还正在开发中,我们的目标是将Qt 6中将要实现的一些新特性在Qt 5.14和Qt 5.15 LTS中发布其略微初级的版本。随着Qt 5.14特性的固定,更多的研发重点将转向Qt 6,我们的目标是在2020年年底前发布Qt 6的第一个版本。在我们深入了解Qt6的新内容之前,让我们回顾一下Qt对用户而言的核心价值,首先明确我们不能更改的内容。

Qt对用户的价值体现在哪里?

Qt已经成功应用与许多不同的行业,并且在不断的横向发展,Qt对用户的核心价值体现如下:

  • 跨平台特性,用户可使用一种技术,把一套代码部署到各种的桌面、移动和嵌入式平台
  • 可扩展性,覆盖了从低端的单用途设备到高端复杂的桌面应用程序和互联系统
  • 世界一流的API、工具和文档,简化了应用程序和设备的开发流程
  • 可维护性、稳定性和兼容性,轻松维护大型代码库
  • 拥有超过100万用户的大型开发者生态

新版本的Qt需要我们进行一些调整以适应新的市场需求,同时也要把上述5个价值观作为我们工作的核心内容。 桌面应用是Qt的基础,也是Qt得以成长和强大的市场,桌面应用是我们大多数用户第一次接触Qt的地方,也是组成Qt工具链的基础。保持桌面应用的健康和成长是在其他市场也保持增长的先决条件。 嵌入式和互联设备是我们增长最快的领域。触屏设备的数量正在以指数级增长,但这些设备的硬件价格却承受着巨大压力。低端芯片组,单片机,结合中小型触摸屏的设备将无处不在。这些设备中的大多数都是功能相对简单的,但它们都需要精致流畅的用户界面。因此我们需要确保我们的产品能够瞄准这个空间,从而实现我们的可扩展的承诺。 与此同时,高端设备的用户界面的复杂性将继续增加,它们往往包括了数千个不同的屏幕和许多的应用程序。将2D和3D元素合并到一个用户界面也是很常见的,增强和虚拟现实的使用也是如此。 人工智能的元素将更广泛地应用于应用程序和设备中,我们需要有简单的方法来集成这些元素。 正在创建的互联设备数量的强劲增长,以及对用户体验的更高要求,使得我们更有必要专注于开发全球领先的工具,以简化应用程序和设备的创建流程。将UX设计人员集成到开发工作流中是我们的目标之一,但是我们还需要在许多其他领域去尝试进一步简化用户的工作。 Qt 6将是Qt的一个新的重大版本,这个版本的主要目标是为2020年以后的需求做好准备,在此次过程中我们将对代码库进行整理,使其更容易维护。重点将放在Qt中那些需要调整软件架构的部分,但是如果不破坏与Qt 5.x兼容性,那这部分就无法完成。 为了适应未来几年的需求,下面是我们会对Qt进行的的一些关键性修改。

新一代的QML

QML和Qt Quick是过去几年推动Qt增长的主要技术。使用这些技术可以直观的创建用户界面是我们产品的一个独特卖点。 QML是为Qt 5创建的,但是它有一些问题和限制。这也意味着它可以大幅改进,我们计划在Qt 6中实现这些改进。我们计划如下: 引入强类型。弱类型使得用户很难对他们的代码库进行大的更改。一个强大的类型系统允许IDE和其他工具帮助用户完成这项任务,并极大地简化了维护成本。此外,它还有助于我们生成性能更好的代码和减少相关开销。 JavaScript成为QML的一个可选特性。使用QML时使用完整的JavaScript引擎会提升复杂性,而且会引起性能上的开销,尤其是在单片机等低端硬件上,性能开销更加明显。然而,这个特性在许多其他应用场景中非常有用。 去掉了QML的版本控制。通过简化QML中的某些查找规则并更改上下文属性的工作方式,我们可以消除QML中的版本控制。反过来,这将大大的简化QML引擎,极大地简化我们维护Qt Quick的工作负担,并为用户简化QML和Qt Quick的使用流程。 删除QObject和QML之间重复的数据结构 目前我们的元对象系统和QML之间有相当多重复的数据结构,这些重复的数据结构会降低启动性能,增加内存使用量。通过统一这些数据结构,我们能够减少许多开销。 避免运行时生成数据结构。这与上面的一点有关,其中许多重复的数据结构目前都是在运行时生成的。其中大多数完全有可能在编译时生成。 支持把QML编译成高效原生的C++代码。通过强大的类型和更简单的查找规则,我们可以将QML转换为高效原生的C++代码,从而显著提高运行时性能 支持隐藏实现细节。为了能够在QML组件中隐藏数据和功能,对方法和属性进行“私有化”一直是一个长期的需求。 更好的工具集成。我们当前的QML代码模型时常不完整,这使得重构和在编译时检测错误变得困难甚至不可能。通过上述更改,应该能够提供与C++相媲美的编译时诊断以及大幅改进的重构支持。

下一代图形

自从Qt 5.0以来,图形领域发生了很多变化,这导致我们不得不对图形栈进行重大更改,以保持其竞争力。 在Qt 5中,我们统一使用OpenGL作为3D图形的API。从那时起,产生了许多新的API。在Linux上Vulkan是OpenGL的指定接班人,苹果正在推动Metal的发展,而微软有Direct 3D。这意味着Qt将来必须与所有这些API无缝地衔接。为了实现这一点,必须定义一个新的图形抽象层的API(类似于平台集成层的QPA),称为渲染硬件接口(RHI)。我们需要将所有的渲染基础设施(QPainter、Qt Quick Scenegraph和我们的3D支持)建立在该层的基础之上。 不同图形API的合成也导致我们必须支持不同的着色语言。Qt着色器工具模块将帮助我们在编译和运行时交叉编译着色器。 3D正在扮演越来越重要的角色,而我们目前的产品还没有一个统一的解决方案来创建同时包含2D和3D元素的UI。目前,将QML与Qt 3D或3D Studio中的内容集成是很麻烦的,并且会导致一些性能开销。此外,在2D和3D内容之间进行逐帧的动画同步和转换还没有办法做到。 3D内容与Qt Quick新的集成方式就是为了解决这个问题。在这种情况下,一个全新的渲染器将允许同时渲染2D和3D内容,并支持两者之间的任意嵌套。这将把QML转换为3D UI的UI定义语言,并且不再需要UIP格式。我们将提供一个新的技术预览版本的Qt Quick与3D支持的版本,它已经包含在了Qt 5.14中,更多的信息将会在一个单独的博文中进行说明。 最后,新的图形栈需要强大的图形素材处理的支持,它能在编译时根据目标硬件预处理这些素材并在需要时使用。比如将PNG文件转换为压缩纹理格式,将许多文件编译为纹理图集,将着色器和网格转换为优化的二进制格式等等。 我们还打算为Qt 6引入统一的主题样式引擎,这将允许我们在桌面和移动平台上获得Qt Widgets和Qt Quick的原生外观。

统一并且一致的工具库

我们创建用户界面的图形工具已经被一分为二,包括Qt 3D Studio和Qt Design Studio。此外,Qt 3D Studio与Qt的其余部分有些脱节,导致了相当多的重复工作。 我们通过将Qt 3D Studio所需的功能合并回Design Studio来统一这些功能。Design Studio与Qt Creator共享了大量代码和应用/插件框架,提供了很好的设计体验,并为我们提供了在设计师和开发者之间搭建桥梁的工具。 设计工具还需要与Photoshop、Sketch、Illustrator、Maya、3D Max等内容创建工具进行良好的集成。 开发者工具需要大量的投入,这样我们才能提供对C++、QML和Python等提供最佳的支持。提供统一工具还意味着开发人员可以很容易地使用Qt Creator中的设计功能,而UX设计者可以从开发者工具的特性(如编译项目或在设备上测试)中获益。 QMake作为Qt 5中使用的构建系统有很多缺陷和限制。对于Qt 6,我们的目标是使用CMake作为标准的第三方构建系统来构建Qt。到目前为止,CMake是C++世界中使用最广泛的构建系统,我们迫切需要更好地与它集成。在QMake上我们将继续支持用户,但不会对其进一步开发或用来构建Qt框架本身。

增强已有的C++ API

C++在过去的几年中发生了很大的变化。虽然Qt 5.0必须以C++ 98为基础,但现在Qt 6可以依赖C++ 17。这意味着C++提供了更多的开箱即用的功能,这在我们使用Qt 5时是没有的。我们使用Qt 6的目标是更好地集成这些能力,同时也保持向前的兼容性。 Qt 6中,我们希望把QML和Qt Quick的一些功能引入到C++中。我们致力于为QObject及其相关类引入一个新的属性系统,将QML中的绑定引擎集成到Qt的核心中,并使其在C++中可用。新的属性系统和绑定引擎将显著降低绑定的运行时开销和内存消耗,并使它们可用于Qt的所有部分,而不仅仅是Qt Quick。

语言支持

在Qt 5.12中,我们引入了对Python的支持,并通过Qt为WebAssembly添加了浏览器作为新的平台。在发布6.0之后,保持并进一步扩展跨平台特性将是Qt 6系列的一个重要部分。

兼容Qt 5和增量改进

与旧版本的兼容性是非常重要的,也是我们开发Qt 6时的主要需求。用户已经使用我们的框架编写了数十亿行代码,因此,我们所做的任何不兼容的更改都会给用户带来额外的成本。此外,对Qt 6的更改要求用户做的工作越多,用户升级的速度就会越慢,这将导致维护Qt 5的最后一个版本的成本更高。 因此,在用户代码中我们应该避免触发编译时或运行时错误进而使得Qt运行崩溃。如果我们必须破坏兼容性,编译时错误比运行时的静默破坏更可取(因为后者更难检测)。 当我们确实需要删除Qt的某些废弃部分,那么我们必须要确保它不会影响用户需要的部分,大部分用户都在使用的关键功能,比如Qt Widgets和其他部分毫无疑问必须保留。 我们正在计划对核心类和功能进行许多在Qt 5中无法实施的增量改进。我们的目标是保持完整的源代码兼容性,但是由于我们可以打破Qt 6的二进制兼容性,我们可以做很多在Qt 5中无法完成的清理和改进。 除了这些,我们还将对Qt 6进行其它的清理。我们将删除Qt 5中已经废弃的大部分功能(函数、类或模块)。从长远来看,这种清理将有助于节省开发人员的时间,并允许我们把更多的精力放在维护和编码上。 然而,对弃用部分的移植需要尽可能的简单,我们的用户可以完美地使用Qt 5.15 LTS增量地完成这一工作。我们的目标应该是Qt 6与Qt 5.15 LTS足够兼容,这样就可以轻松地维护一个可以同时针对两个版本编译的大型代码库。

市场和技术产品结构

除了改进Qt框架和工具,我们的目标是为组件和开发工具创建一个新的市场。这个方向将面向开发、设计应用程序和嵌入式设备的直接使用者,而不是面向最终用户。因此,它将成为Qt生态系统的一个凝聚中心。它将为第三方厂商提供一个发布Qt扩展组件的场所,扩展可以是免费或商业的。 Qt在过去的几年里增长良多,当前最重要的任务就是发布一个新版本。在Qt 6中,我们有机会重组我们的产品,并将必要的框架和工具打包为一个更小的核心。我们将利用应用市场来交付我们的附加框架和工具,而不是作为与核心Qt产品紧密耦合的捆绑包。这将使我们在何时交付以及如何交付方面具有额外的灵活性,并允许我们为某些附加组件解耦发布计划。

欢迎你的参与和反馈

在Qt 6第一个版本发布前,技术概览将逐步完善。虽然我相信本文档为Qt的下一个版本奠定了基础,但它肯定还有很多需要完善的地方。如果您有任何新的想法,请参与到Qt 6的开发中,并遵循Qt的开放性管理规则进行讨论。

Subscribe to Our Blog

Stay up to date with the latest marketing, sales and service tips and news.

R
Roman Nikulenkov
3 points
38 months ago

Sounds nice. But in reality, Qt Quick is not suitable for serious desktop tasks due to the lack of full-fledged components for working with tables and trees. Qt Widgets hasn't been developed much in many years. Only minor improvements and bug fixes.

C
Carl
1 point
37 months ago

Within KDE we built a few very complex QtQuick app outside of Plasma Desktop itself. Two of them are Kalendar and NeoChat where I'm personally involved and botha desktop and mobile application. Kalendar has a very desktop-ish mode with tree views (using kirigami-addons treeview implementation), a menu bar with configurable shortcuts, command launcher, resizable sidebars and many complex views for the month and week view. https://apps.kde.org/kalendar/ When developing the apps we encountered a few issues:

  • lack of real dialogs opening in a new window => we ended up developing out own by creating a new ApplicationWindow

  • kxmlgui (a qtwidets framework) didn't integrate well since it uses Q{Gui}Action instead of the qtquick controls 2 private api QQuickAction. We wrote wrappers but it would be very nice to merge the two so that ugly wrappees are not needed anymore.

  • Lack of a Tree view for the task view in QQC2 -> we ended up using the kde implementation that internally transform a tree view in a list view with some additional role for the nesting information. Looks pretty nice but i'm looking forward qt6 tree view implementation. Hopefully it handles keyboard navigation and Right to Left layout out of the box

  • many other issues like right click event handling for text areas or consistent styling with QtWidgets apps are already solved by qqc2-desktop-style and Kirigami: https://api.kde.org/frameworks/kirigami/html/ and https://api.kde.org/frameworks/qqc2-desktop-style/html/

Peter S.
0 points
37 months ago

... and the lack of right mouse click support for many built in Qt Quick controls - WTF?

F
Flavio
3 points
38 months ago

Qt on Linux desktop has been shipping for years without any integration with GNOME, it does not even pick the system color palette. At the very least, picking system colors and shipping a modern style (i.e. not Fusion) will fix the terrible user experience.

Peter S.
2 points
37 months ago

One point which speaks against Qt when discussing SDKs with our customers is the user interface. The Material theme is heavily outdated, there is no iOS style, and the widgets style is outdated too. I hope that the work mentioned in the 2022 roadmap will improve this.

Olivier Mb
1 point
38 months ago

This sounds good. Qt has a tremendous unexploited potential in the mobile sector, same could be true for webassembly as well.

A
AngryCustomer
1 point
38 months ago

Good Lord give us a break with all that marketing non sense! Nobody gives a fuck about your 3D particles or mesh morphing on the desktop! A decade (!) of neglect is hardly caught up in 2022. Qt Widgets is kept alive with an absolute minimum of effort, outdated and without any support of anything you'd expect from an up to date widget system (want to write some qss files for me?). Quick Controls 1 was a start (although a CPU-hungry one) but ditched for Controls 2 that never even came close in (desktop) functionality. In Controls 2, you have to write even the most trivial desktop stuff again and again (mouse wheel handlers in SpinBoxes seems to be too much to ask). Mobile platforms were THE THING in your marketing in 2015ish and quickly abandoned when you focused on embedded, leaving your (and then mine) customers with half baked solutions, odd behaving Uis and, in the end, a recommendation to buy Felgo licenses on top for even more money to fix the promises you never kept. Yes, your rip off licenses are totally worth 3k a year. This is so pathetic.

M
Mitch Curtis
1 point
37 months ago

mouse wheel handlers in SpinBoxes seems to be too much to ask

Setting the wheelEnabled property to true does this. For any other problems you're having with Controls, please report them so that we can address them.

S
Sébastien Wilmet
0 points
37 months ago

Qt is hiring, so we can hope that the situation can be improved, if what you describe is true.

Qaler Qi
1 point
37 months ago

Qt company just reminds me of Nokia, once popular but not anymore, maybe the stock price makes them so full of arrogance.