我即将用C++为我的MSc项目编写一个软件,我希望以此为契机学习Linux本机API或Qt API,这两者都是我感兴趣的,但我是不确定哪一个更合适.如果这个问题看起来漫长,令人费解并且有些含糊不清,我很抱歉,但我担心如果我现在做出错误的决定,它可能会破坏整个项目.
我要创建的应用程序在界面方面几乎没有.它将和一个配置菜单,一些带有进度条的对话框通知用户发生的事情,以及一个使应用程序能够完成任务的按钮.从长远来看,我打算在Windows,Mac OS和Linux上部署这个应用程序,这个按钮在每个平台上都有不同的位置(Linux上的Gnome面板,Windows上的系统托盘,以及Mac上调用的任何面板) OS).
其余部分将在后台运行,当用户按下按钮使其运行时,它将查找有关当前正在运行的应用程序的某些信息,将其编译为XML文件并同步,通过服务,我也将自己制作并托管和运行Linux的Amazon EC2实例.当他们登录到连接到此EC2实例的另一台计算机并点击"应用程序转到"按钮时,同步数据将被下拉并放在他们的计算机上.
现在我的问题:
这里有什么更好的API选择:native还是Qt？虽然Qt似乎是跨平台应用程序的明显选择,但我的一些担忧是:
虽然我已经提到我希望它是跨平台的,但是我已经使用下拉菜单移植到平台的应用程序有一些非常糟糕的经验,如果它导致了一个客户端应用程序,它将很乐意重写它用户体验的实质性改善.
cha*_*ley 11
我投Qt.Qt代码库很好地考虑了将" QtCore"库与" "库QtGui分开." QtCore"包括对进程/线程,信号/槽和状态的支持,类似于GUI组件"独立"使用的状态.(例如," QSlider"小部件仅仅是一个GUI组件,它呈现由库中的实际组件管理的状态QtCore,这对于检查范围内的值的边界非常有用,即使在非范围内也可以很好地应用GUI应用程序,如硬件控制系统.)
对于某些问题,信号/插槽独特地提供了许多设计选项(灵活性).它基本上允许不直接耦合的类型和对象之间的通信/信令(例如,当两者都不包括另一个的头部时).虽然并非所有设计都能保证这一点,但它对于进程间通信,硬件控制系统,灵活扩展的模块系统和GUI应用程序而言是动态且强大的.
最后,像流程/线程这样的"方便"事物的跨平台包装非常好,通过信号/插槽的线程安全非常好,读/写编解码器,文件解析和媒体文件支持非常好,它有" QDesktop"类型的东西,使你的"图标托盘"和其他平台特定的实现更容易.
Qt是不是所有的古怪,当你不使用QtGui图书馆.(如果你不想链接-= QtGui,请务必使用" ",qmake这不是什么QtGui.lib大问题.)
如果我在不使用GUI小部件的情况下尝试做事,Qt会变得古怪吗？
不.但是,它确实有构建要求(例如,"moc").
是原生的(因此,深入到操作系统中)是否过度杀戮这样的事情？
不,但是根据你的语言,你需要支持线程,进程,编解码器等.所以,Qt可以简化它(因为那些不是由C/C++语言直接处理,你需要一些库类).
鉴于应用程序将在后台运行,因此与其他应用程序一起运行,Qt以及它带来的附加抽象层会对用户会话的其余部分的性能产生不利影响吗？
不可以.对于跨线程和跨进程的通信,它将尽可能快地获得.对于GUI,它将与任何GUI(但可能是任何GUI中最快的GUI)相提并论.
如果我使用Qt,那么将"应用程序转到"按钮放在每个平台上的适当位置之类的"打破"Qt包装器是多么困难.
非常简单 - 它是跨平台的,但您具有极大的灵活性,可以进行特定于平台的耦合.(例如,在MFC-app中嵌入Qt很容易,在Qt app中嵌入MFC很容易,混合QML/Qt-Widgets很容易,等等)