Qt 6 中的 Qt Extras 模块 [复制链接]

### 一、前言
1. Qt 6 是有意识地努力使框架更加高效和易于使用的结果。
2. 我们尝试在每个版本中保持所有公共 API 的二进制和源代码兼容性。
3. 但为了使 Qt 成为更好的框架，一些更改是不可避免的。
4. 其中一项更改是删除特定于平台的 Extras 模块，以确保 Qt 6 的跨平台故事和未来具有凝聚力。
5. 这些模块提供的大部分功能已被其他 Qt 模块中的类似功能所取代，例如通过新的平台 API。

其余 API 通常属于以下三类之一：
- 该功能在相关平台中已被弃用。
- API 没有已知的内部或外部客户端。
- 该 API 与其他平台上的类似 API 重叠，保证了跨平台 API。
- 对于后两种情况，我们将继续调查未来版本是否需要替换 API。

### 二、Qt Mac Extras 的变化
#### 2.1 QtMac 命名空间
QtMac 命名空间的大多数成员都有显式替换。由于缺少 API 的已知客户端，该功能已被删除。例如 QtMac::fromCGImageRef 。

#### 2.2 QMacPasteboardMime
由于保证跨平台解决方案，该类已被删除。有关详细信息，请参阅QTBUG-93632。

#### 2.3 QMac工具栏
QMacToolBar  QMacToolBarItem 类已被删除。使用QToolBar作为替代。还有第三方解决方案，例如MacHelper库。

### 三、对 Qt Windows Extras 的更改
#### 3.1 QtWin 命名空间
QtWin 命名空间的许多成员都有显式替换。要将这些替换与 Qt Widgets 或 Qt Quick 一起使用，请对相关小部件或控件的QWindow表示进行操作。  

其余功能已被删除：
- 错误字符串从结果仅在 WinExtras 内部使用。没有其他已知的 API 客户端。
- colorizationColor/isCompositionOpaque概念存在于其他平台上（色调/强调色）。保证新的跨平台 API，例如新的QPalette角色或平台主题属性。
- setWindowFlip3DPolicy Windows 7 功能。Windows 10 不再支持。
- 扩展框架进入客户区，其他平台上也存在类似的功能。
- 保证跨平台QWindow API 来控制客户区和非客户区（框架/标题栏）之间的关系。有关详细信息，请参阅QTBUG-94010。
- 启用BlurBehind，自 Windows 8 起弃用。
- taskbarActivateTab 和 taskbar(Add/Delete)Tab 没有已知的 API 客户端。

#### 3.2 QWinMime
由于保证跨平台解决方案，该类已被删除。有关详细信息，请参阅QTBUG-93632。
仍然依赖该功能的客户端可以包含私有 <QtGui/private/qtguiapplication_p.h> <QtGui/private/qwindowsmime_p.h>，并使用 QWindowsApplication 本机接口来注册新的 MIME 类型。

#### 3.3 QWinJumpList
由于保证跨平台解决方案，QWinJumpList QWinJumpListCategory QWinJumpListItem 类已删除，有关详细信息，请参阅QTBUG-94007。

#### 3.4 QWinTaskbarButton
由于保证跨平台解决方案，QWinTaskbarButton  QWinTaskbarProgress 类已被删除。有关详细信息，请参阅QTBUG-94009和QTBUG-94008。

#### 3.5 QWinThumbnailToolBar
由于缺乏知名客户端使用示例。QWinThumbnailToolBar QWinThumbnailToolBarButton 类已删除。

### 四、Qt X11 Extras 的变化
1. QX11Info 类已被删除。
2. 所述QX11Info ::连接（）和QX11Info ::显示（）方法已经被替换为QX11Application为本地接口QGuiApplication。
3. 仍然依赖该功能的客户端可以包含私有头<QtGui/private/qtx11extras_p.h>作为权宜之计。
4. 要启用私有标头，将项目依赖项添加到pro。 QT += core-private

### 五、Qt Android Extras 的变化
1. 该模块的关键功能已转移到其他 Qt 模块中。
2. 仍然依赖该功能的客户端可以包含私有头<QtGui/private/qtandroidextras_p.h>作为权宜之计。
3. QAndroidJniObject 和 QAndroidJniEnvironment 已被QJniObject和QJniEnvironment分别取代。
4. QAndroidJniExceptionCleaner类已被 QJniEnvironment :: checkAndClearExceptions（）取代。  
5. QtAndroid 命名空间的许多成员在QAndroidApplication本机接口中都有替换。
6. 权限请求 API 已被跨平台QCoreApplication::requestPermission () API取代。

变化还是挺大的

估计永远不会升级到qt6,因为太多用户是用的win7

6.2估计开源用户升级不了了

开发环境不支持win7可以理解,发布平台也不支持,就有点扯蛋了

angelus:开发环境不支持win7可以理解,发布平台也不支持,就有点扯蛋了 (2021-09-22 16:09) 

并不扯蛋，试想一下5年前一款软件不支持XP是什么性质

沉默小ai:[表情] 6.2估计开源用户升级不了了[表情]  (2021-09-22 08:25) 

印象中，6.2.0开源用户可以使用。后面的就不知道了。

Qt6只能win10使用确实一个问题

Android这里修改了这么多，那暂时不打算升级了。

沉默小ai:[表情] 6.2估计开源用户升级不了了[表情]  (2021-09-22 08:25) 

看描述，是说的6.3出来后，6.2版本的修复补丁只给商业用户了。开源的升级版本是6.3,说白了是小白鼠，帮测试新版本的

yfy002:看描述，是说的6.3出来后，6.2版本的修复补丁只给商业用户了。开源的升级版本是6.3,说白了是小白鼠，帮测试新版本的 (2021-09-28 22:09) 

到时候只能看kde给力不给力了。
5.15这边kde还是很给力的，还在维护自己的分支，虽然他们说不会发布二进制包。
Arch Linux目前已经使用kde的Qt5分支相当长一段时间了，不知道其他发行版会不会适配。

我目前准备编译一下试试看kde的分支到底怎么样，如果能在2023年5月EOL之前保持长期更新的话，我可能会把kde分支拿来做Qt5的最终版的长线的编译作业。

fsu0413:到时候只能看kde给力不给力了。
5.15这边kde还是很给力的，还在维护自己的分支，虽然他们说不会发布二进制包。
Arch Linux目前已经使用kde的Qt5分支相当长一段时间了，不知道其他发行版会不会适配。
....... (2021-09-29 22:31) 

有没有进展？

hehui:有没有进展？ (2022-07-29 14:45) 

我在今年年初的时候编译出了第一个版本的kde版。
然后因为kde更新不发布新版本，所以我的调查也就停留在第一版了，并没有继续编下去。