12

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++?

Community
  • 1
  • 1
Ozzah
  • 10,631
  • 16
  • 77
  • 116
  • The primary question has been done to death if you brows the site a little bit, and the last question is very open-ended. – San Jacinto Feb 21 '11 at 03:08
  • Realize that the Windows API is not a GUI toolkit. It's a low-level interface to the operating system for applications. Of course you would need frameworks for anything nontrivial. You are correct that this is where frameworks come in. – In silico Feb 21 '11 at 03:11
  • I wouldn't consider Mono a "hack" – Earlz Feb 21 '11 at 03:22
  • Also, it is important to note that C/C++ is considerably lower level than C#. This means, by definition, it will be more verbose for things like this no matter what GUI framework you use. – Earlz Feb 21 '11 at 03:24

2 Answers2

5

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.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • Thanks for the wonderful, descriptive answer! I appreciate your insight into the accepted design trends which differ between platforms - something I hadn't considered. I guess the reason I called mono a 'hack', in hindsight a somewhat strong word, was because it is unsupported by Microsoft and in my experience more complicated .Net classes didn't work as expected, e.g. Sockets etc. – Ozzah Feb 21 '11 at 03:47
  • @Ozzah: Lots of things are unsupported by Microsoft, mainly because they didn't create them. They certainly have made no efforts to *discourage* the Mono Project, and in fact, have been surprisingly supportive. While Microsoft's own CLR is a proprietary piece of software, the .NET languages (like C#) are based on open standards, and community involvement is encouraged. Microsoft has even pushed .NET as a platform-independent product, which can really only be achieved through the efforts of contributors to projects like Mono. There are a few holes in their implementation, but not many. – Cody Gray - on strike Feb 21 '11 at 04:03
  • @Ozzah: You'll find a more complete compatibility list [here](http://www.mono-project.com/Compatibility), but from what I understand, the most gaping hole is the absence of WPF support. Just about everything you need for a WinForms app is there and works great. As far as failing to consider the different design trends between platforms, don't feel too bad. Most people *don't* consider these things, and it's probably one of my soapboxes. I'm a Mac user with their sense of style and aesthetics, who develops on Windows so I'm stuck with that platform and its sometimes egregious inattention to UI. – Cody Gray - on strike Feb 21 '11 at 04:06
  • WARNING: Stay away from Mono's implementation of Windows Forms! The developers [say it is no longer being developed](https://bugzilla.xamarin.com/show_bug.cgi?id=17359), so they are not fixing any bugs. In my experience, it is [totally unusable on Mac OS X](http://lists.ximian.com/pipermail/mono-winforms-list/2013-September/004923.html) (e.g. controls don't get painted in the app I tried, and user keystrokes are processed in the wrong order). It is usable on Linux but sometimes users report segmentation faults coming from it. – David Grayson Dec 28 '14 at 02:09
3

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.

Javier
  • 60,510
  • 8
  • 78
  • 126
  • 4
    You know, I use Qt daily and I like it for a lot of reasons. This, however, is a useless answer. You gave a bunch of subjective claims of awesomeness and failed to mention the pitfalls. You also failed to mention the recent questions of Qt instability due to Nokia's business decisions. In short, this is not the type of answer I would expect from an SO member with 17K rep. – San Jacinto Feb 21 '11 at 15:10
  • 'subjective'? these are simple adjectives, but objectively verifiable. the pitfalls i've found frequently mentioned are more subjective, like "it's not real C++", or "manual memory allocation is hard". Nokia's current mismanagements affect only the popularity on mobile platforms, not the viability on desktop. – Javier Feb 21 '11 at 19:02
  • 2
    "Most complete?" "Most mature?" Those are objectively verifiable? By whose standard and whose application? But either way, _VERIFY_ them with your answer. Link to stuff. Show data. That's my point. Otherwise, these are just subjective "my framework is better than yours" claims and the noise-to-data ratio on SO continues to grow. Also, I would add that there are _real_ pitfalls with using the framework, and that doesn't mean that it is therefore a steaming pile. It's all about tradeoffs we as Qt devs are willing to make. – San Jacinto Feb 21 '11 at 19:16