我要创建的应用程序在界面方面几乎没有.它将和一个配置菜单,一些带有进度条的对话框通知用户发生的事情,以及一个使应用程序能够完成任务的按钮.从长远来看,我打算在Windows,Mac OS和Linux上部署这个应用程序,这个按钮在每个平台上都有不同的位置(Linux上的Gnome面板,Windows上的系统托盘,以及Mac上调用的任何面板) OS).
其余部分将在后台运行,当用户按下按钮使其运行时,它将查找有关当前正在运行的应用程序的某些信息,将其编译为XML文件并同步,通过服务,我也将自己制作并托管和运行Linux的Amazon EC2实例.当他们登录到连接到此EC2实例的另一台计算机并点击“应用程序转到”按钮时,同步数据将被下拉并放在他们的计算机上.
现在我的问题：
这里有什么更好的API选择：native还是Qt？虽然Qt似乎是跨平台应用程序的明显选择,但我的一些担忧是：
>如果我在不使用GUI小部件的情况下尝试做事,Qt会变得古怪吗？
>对于像这样的东西来说,是原生的(因此,深入到操作系统中)是否过度杀伤？
>鉴于应用程序将在后台运行,因此与其他应用程序一起运行,Qt以及它带来的额外抽象层会对用户会话的其余部分的性能产生不利影响吗？
>如果我使用Qt,那么将“应用程序转到”按钮放在每个平台上的适当位置之类的“打破”Qt包装器是多么困难.
虽然我已经提到我希望它是跨平台的,但是我已经使用下拉菜单移植到平台的应用程序有一些非常糟糕的经验,如果它导致了一个客户端应用程序,它将很乐意重写它用户体验的实质性改善.
解决方法
对于某些问题,信号/插槽独特地提供了许多设计选项(灵活性).它基本上允许不直接耦合的类型和对象之间的通信/信令(例如,当两者都不包括另一个的头部时).虽然并非所有设计都能保证这一点,但它对于进程间通信,硬件控制系统,灵活扩展的模块系统和GUI应用程序而言是动态且强大的.
最后,像流程/线程这样的“方便”事物的跨平台包装非常好,通过信号/插槽的线程安全非常好,读/写编解码器,文件解析和媒体文件支持非常好,它具有“QDesktop”类型的东西,使您的“图标托盘”和其他平台特定的实现更容易.
当你不使用QtGui库时,Qt并不是很古怪. (如果你不想链接QtGui.lib,请确保在你的qmake中使用“ – = QtGui”,这不是什么大问题.)
Will Qt become quirky if I try to do stuff without using the GUI
widgets?
不.但是,它确实有构建要求(例如,“moc”).
Is going native (and thus,pretty deep into the OS) overkill for
something such as this?
不,但是根据你的语言,你需要支持线程,进程,编解码器等.所以,Qt可以简化(因为那些不是由C/C++语言直接处理,你需要一些库类).
Given that the app is going to be running in the background,and thus
alongside other applications,will Qt,and the additional layers of
abstraction it will bring with it,have a detrimental effect on the
performance of the rest of the user’s session?
不可以.对于跨线程和跨进程的通信,它将尽可能快地获得.对于GUI,它将与任何GUI(但可能是任何GUI中最快的GUI)相提并论.
If I use Qt,how difficult will it be to ‘break out’ of the Qt wrapper
for things like placing the ‘application go’ button in the
appropriate location on each platform.
非常简单 – 它是跨平台的,但您具有极大的灵活性,可以进行特定于平台的耦合. (例如,在MFC-app中嵌入Qt很容易,在Qt app中嵌入MFC很容易,混合QML / Qt-Widgets很容易,等等)
