如题，我发现UOS商业版和deepin V23 RC版在DTK开发的编程语言选择方面不太一样。

首先，UOS商业版现在更注重其应用软件的稳定性，对Qt5 Widget C++编程的文档编写更完善。而deepin V23 RC版本，则开始大量使用Qt Quick提供的描述语言QML来编写原生应用的界面。

尽管使用QML还会时不时的编写一些C++代码内容，但是以目前UOS/deepin最终的桌面形态来讲，QML的代码编写风格会让应用程序客户端开发者能够更加接受，C++会更多以中间件、服务端或云端服务的形态进行出现。

况且，Qt Quick随着qt库的升级和完善，QML的业务处理也会逐渐减少C++代码的编写，还能增强对wayland视窗协议的支持。

我再次想说一下：

Qt C++开发应用，虽然能让Qt应用在运行时变得稳定，但是现在PC硬件的存储容量在同价位上都能得到增加，性能方面已经不再是最极端的选择。而且，Qt C++在Qt库版本升级后，有些编程写法和以前都不太一样，甚至一些旧版本的应用程序源代码也不能直接在Qt 新版本中正常运行，会导致旧版本的应用程序需重新升级Qt库和改代码。以qt4、qt5和qt6的信号与槽的C++代码编写风格，其案例如下：

(1).Qt4版本，C++代码编写的信号与槽

(2).Qt5版本，C++代码编写的信号与槽

(3).Qt6版本，C++代码编写的信号与槽

从上面的代码Qt C++代码对比来看，Qt4版本的写法和Qt5、Qt6之间不太一样，但Qt5、Qt6的信号与槽写法更加明确，这就说明不同Qt版本，C++的新特性和新的编写方式不能向之前兼容，旧项目源代码必须重新重构和编写实现，才能更好去维护，也会导致Qt C++的学习周期变长。

在当今的应用软件开发领域、web端开发领域，界面程序开发者他们更希望编写界面和业务逻辑的代码在版本更迭时不会有大的变动，而是API库或SDK工具集直接升级、或直接更换，不会让前端view和业务代码有太太变化。

我的意思就是：把之前的Qt C++通用的代码和核心类封装为Sdk或其他API库，qml开发者对应用升级(升级，主要是程序的性能、界面动画的效率等等)，可直接升级其Qt C++库版本或DTK C++库版本，QML编写的代码基本开发者不再大动干戈。

当然，QML编写的应用程序也不是没有其它bug出现，我只是想让官方在QML对应的Qt C++库和源码进行封装和版本维护，并让QML的编写风格和开发者都能稳定下来，避免把后面更多时间用在处理qml。

最后，我还是希望官方能对QML的支持力度更大一些，尤其是官方的DTK文档不管是UOS版还是deepin版能够统一一下。在DTK核心库基本确定的条件下，去更多让QML试错并得以快速改善，而不是继续在Qt Widget C++代码上花更多时间。