@青山白云 使用Qt Installer Framework也是可以的,需要拿它的项目改一改样式就可以达到想要的效果。如果不在意没有无边框效果这个缺陷的话,那么指定ui文件也是很方便的。

jcy 发布的帖子
-
RE: qt程序打包发布
-
中大型Qt项目目录组织
Hi,很久都没有写一些经验文章了。最近终于空出时间,我开始静下心来,将自己过去遇到的各种问题总结一下,有关中大型基于Qt的项目目录的组织方法。
如果您是第一次使用Qt,那么可能会按照自己的喜好去创建项目。这样创建的项目简单,更为使用者所理解。但是如果你是想创建一个长期的项目并且希望其他人与你一同协作,那么项目的组织就变得非常重要了。好的中大型项目必须做到以下几点:1、对持续集成友好
何为“持续集成”?就是可持续构建、流水线操作的方式来处理软件系统。因为中大型项目的构建往往需要花费较长的时间,并且软件是一个系统中唯一需要人工开发部分(作为对比,硬件制作自动化程度非常高),所以为了满足快速发布的需要,我们必须构建一套持续集成的系统。以满足一日一版本甚至一日多版本的发布测试需要。举个例子:在固定的开发周期内(比方说三个月),手工构建的方式需要集合所有团队的成果,然后各个部门的成果集合起来,假设需要两天,那么以每个月22个有效工作日的情况下,最多只能构建33次版本,而且要让所有的团队成员做重复劳动至少33次。假设搭建了持续集成的环境,可以缩短到一个小时构建一次,那么以每天八个小时工作计算,理论上说可以构建66×8次版本,大大超出的了手工构建的方式。这对于测试部门和开发部门来说,节省了宝贵的时间用来测试和后续开发,都是大有意义的。
2、配置型
大型项目最好能够做到项目可配置。这是因为软件的运行依托的是硬件,硬件的配置千奇百怪,这需要相对完整的软件测试。我们的流程是根据不同硬件上的软件测试来针对我们的项目选择最优的策略。这个时候谁都不希望为一个小小的改动而返工,并且软件产品一旦发布到用户的手上了,那么在想引导它们重新安装就变得很难了。因此希望有一套策略,自适应客户的环境,并且给出最佳的使用方案。这也是为什么很多软件都有“设置”功能的原因。那么一些超出用户认知以外但是可能需要根据不同环境适配的内容,宜写成配置文件,配置文件为空,程序内部逻辑给出默认值。
3、有多个测试案例
大型项目往往是多个小功能聚集起来的,那么大型项目可能会遇到千奇百怪的情况,一般的方式很难检查出来,而且问题的复现路径将变得很长。那么为了尽量减少此类情况的发生,缩短问题的复现路径,找到问题的原因,主要也是为了复测遇到的问题,有必要构建多个测试案例。测试案例要尽量写得简单一些,能够直接验证问题是否解决为佳。
4、模块化管理
好的软件,都是利用模块化管理的。虽然模块化会导致应用程序安装包变得庞大,并且增加了进程注入的风险,但是这确是大规模协作可行的办法。试想一下,用户使用了发布的软件出了问题,假设不使用模块化的方式,那么出了问题,定位到问题点可谓十分困难,即使找到问题并且解决了,但是要客户重新安装并且部署软件,又是一个非常繁杂的过程。所以友好的方式是将各个功能分为不同的模块,出了问题的话,容易定位到哪个模块出了问题,并且可以通过替换有问题的模块来解决相应的问题。使用模块化的方式还有一个好处,那就是职责分明。将软件开发过程中形成的优秀代码打包出售,也可以将不合格的模块进行替换,不至于影响其他模块的正常工作。还可以以此评定成员在项目中的贡献。
除此之外,还有很多优化的方法,比如说“开-闭原则”等等,都是方便用户使用或者方便开发者开发而采用的方法。
那么,中大型Qt项目,究竟是怎么组织的?
我们可以看看Qt作为一个二十多年产生的项目,它的代码是如何组织的。大家只要去Qt开源软件下载网站 去下载相应的源代码,就可以找到他的组织方法。以下是我们的商业软件代码的组织:一般包括examples、src、test和其它文件。其中src里面包含的是源代码,非常重要。也是我们经常需要添砖加瓦的一个文件夹。此外,如果是QML插件模块,那么需要在src文件夹中添加一个imports文件夹,和Qt的命名风格保持一致。其中src中每一个子文件夹都是一个子项目,其中pro文件的编写都有相应的规则。这超出了本文介绍的范围,要单独一篇文章介绍才行。