用 C++ 编写 GUI 应用程序时最好使用什么库?
可能的重复:
Gui 工具包,我应该使用哪个?
我有相当多的C/C++ 经验 - 主要用于为 Windows/Linux 编写控制台应用程序,还有相当多的 C# 经验 - 通常用于编写 WinForms 应用程序等。
我可以轻松地在 .net 中创建窗口,这给我留下了深刻的印象,例如,简单的事情
Form form = new Form();
form.ShowDialog();
就足以在屏幕上显示一个空白表格。事实上,
new Form().ShowDialog();
只要我们不介意在表单关闭后丢失对表单的引用,从技术上讲就足够了。
我尝试过使用 windows.h
用 C++ 编写一些基于 Windows 的 GUI 内容,但不仅学习曲线看起来有点陡峭,而且语法也非常冗长。使用 windows.h
创建一个像上面提到的单行 .net 实现这样的简单窗口可以轻松超过 2 打行。
但不仅如此,如果我要将应用程序移植到 Linux/Max(这是我在 .net 上几乎无法做到的事情,除了像 mono 等 hacks 一样),那么我需要重写 95%图形用户界面代码。
我假设这就是框架的用武之地,例如 QT 等...(恐怕我对 gui 框架不太了解)。
您推荐哪些 GUI 框架?哪些是最强大的,哪些是最容易使用的? 您通常如何处理用 C/C++ 编写 GUI 的任务?
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h
, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h
.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
编程越接近金属(可以这么说),事情就越困难。考虑到复杂性,WinForms(由 .NET Framework 提供)是 Win32 API 的一个非常出色的抽象您已经看到它涉及甚至最简单的任务,例如让窗口出现在屏幕上。当然,所有这些仍然在后台发生(注册窗口类、创建窗口等),您只是不必自己编写代码。
有趣的是,您将 Mono 视为“黑客”,但会考虑像 Qt 这样的库。我真的不确定你是根据什么做出区分的。在 WinForms 支持方面,Mono 库被广泛认为优秀。最大的缺点与 Microsoft 自己的 CLR 实现相同,即它不会生成真正的本机代码,这在大多数情况下与性能的关系比人们想象的要大。除此之外,有些人抱怨 Mono 应用程序不完全符合平台的 UI 准则(也就是说,它们的外观和行为与本机应用程序不完全相同),但我对使用 Qt 编写的应用程序也有类似的抱怨。
如果你想用 C++ 进行 GUI 工作,似乎每个人都推荐使用 Qt。正如我上面提到的,它恰好不是我最喜欢的库,因为我坚持使用当前运行的平台提供的完全本机控件和小部件。我知道 Qt 最近在这方面有所进步,但我仍然认为它没有达到我的标准。如果您比我更灵活(我会警告您,普通 Mac 用户并不比我更灵活),并且真正的平台独立性是您最关心的问题,那么也许是您应该选择的一个。许多人称赞它的设计优雅和方便,尽管我严重怀疑它是否能提供与 .NET Framework 的实现相同的简单性。
如果代码的纯粹简单性和简洁性与问题开头听起来一样重要,那么我强烈建议坚持使用 C# 和 WinForms。当您开始消除抽象层时,事情会变得更加困难,并且如果您不需要这样做所提供的额外控制级别,那么几乎没有任何理由为自己做更多的工作。假设您的需求相对适中,Mono 的 Forms 实现对于跨平台应用程序来说是一个完全可行的解决方案。
除此之外,如果您想以正确的方式用 C++ 创建真正的跨平台应用程序,我建议您将数据层代码与 UI 层严格分离,然后使用工具编写 UI由您想要支持的每个平台提供。在 Windows 中,您的选择相对开放:.NET WinForms 是一个可靠的选择,本机 Win32 是一个有点痛苦但值得的选择,而一些其他库(如 MFC 和 WxWidgets)可以帮助减轻完全本机编程的痛苦(尽管不是)几乎和 WinForms 一样)。在 Mac 上,唯一真正的选择是 Xcode、Interface Builder 和 Objective-C(针对 Cocoa 框架)。基于 Linux/Unix 的系统很难是我的强项,但我知道 Qt 是您能找到的最原生的库。这听起来比我想象的要多——一个设计良好的库应该处理 80% 的工作,只留下大约 20% 的工作需要你在实现 UI 时完成。除了使用真正的本机控件和小部件之外,我认为这种方法提供的另一大优势是灵活性。请注意,Microsoft Word 在 Windows 上的外观与在 Mac 上的外观非常不同(尽管有一些表面上的相似之处)。 iTunes 在 Mac 平台上几乎已经成为优秀 UI 设计的典范,但在 Windows 上却显得很突出。另一方面,如果您在 Mac 上推出类似 Windows Media Player 之类的东西(是的,微软自己也尝试过,尽管没有取得多大成功),Mac 用户会认为它完全是令人厌恶的东西,并且可能会有些生气。甚至尝试过。对于真正具有跨平台思维的开发人员来说不太好。综上所述,如果您的应用程序不是最简单的实用程序,您可能会发现每个应用程序上的完全不同的界面是合理的(甚至预期)您想要支持的平台。
无论 Qt 多么出色,您都无法用它来实现这一目标。
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt,放下手。
它是目前最完整、最成熟、最快的框架。最重要的是,它是真正的多平台,您可以选择商业友好的开源或付费支持。
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.