Qt goes LGPL! On Windows, is it good enough to use instead of MFC?

Question

I just read a story I was hoping to read since Nokia bought Trolltech. Qt is going LGPL in March!

This is awesome news.

Who uses Qt for Windows? Does it effectively replace something like MFC? Sure, I can RTFM (and to some degree I have)... but what do people USING Qt on a Windows platform think of it?

I still do quite a bit of MFC work, which has always bothered me. I'm somewhat fluent in it, so I've put off switching. I was wanting to use the switch as an opportunity to do more Linux development.

I'd done a comparison a year or so ago comparing cross-platform GUI toolkits, and came to the conclusion that the only one I'd touch was Qt.

I could not use Qt before, because the code I write for clients is almost never open source. Even if I personally bought a commercial license, my clients would need to be able to compile and use the source I wrote too, and I couldn't buy all my clients licenses (or require that they purchase them).

So... I really need to junk MFC. If you're a Qt developer, are you happy with it? Remember, I'd be using it primarily on a Windows platform (for now).

Answer 1

I did a lot of MFC at one point, and found that wxWidgets was an easy leap.

Answer 2

It depends on what you want to do with it. I've done a medium complexity wizard application in Qt and found it to be pretty straightforward. There is a bit of a shift from the Windows message queue to the Qt signal/slot paradigm. I found the signal/slot idea relatively easy to understand.

Compared to MFC, I found the documentation lacking. The UI design tools were also a bit of a struggle, but the underlying file format is XML and human readable to some extent unlike MFC resource files.

Answer 3

There is a MFC migration guide from Nokia, and a nice MFC to Qt migration walkthough to explain things.

Currently there is a slashdot thread where the consensus is that this is a Very Good Thing indeed and that its going to herald a new dawn in GUI development (for Linux, and possibly from disgruntled MFC developers).

It's probably a good idea to go with it, the downsides are limited, the benefits could be considerable, considering its cross-platform abilities (and I refer to QTEmbedded for mobiles as well as Linux, Mac, and WindowsCE.). Qt is a good library, has some advanced features such as QGraphicsView, binds to practically every language out there (including C# using Qyoto) So.. the question is less 'who uses it now' and more 'who will be using in the future'.

Answer 4

I've written a lot of Qt4 code for deployment on Windows, but have not used MFC. I enjoy Qt and can't think of a reason to use anything else for GUI development now that it is LGPL. The only time you need to break out of Qt is to do low-level things, like accessing the serial port. Mouse/Keyboard/GUI/Audio/Video stuff is abstracted across all supported platforms.

Answer 5

Google Earth is written in Qt, and KDE, Adobe Album, Skype on Linux, the Roku Netflix player, Opera and a number of other commercial uses. The German Air Traffic Control (DFS) has a Qt-based system, so each time you fly through Germany your plane is being guided using a Qt application. See http://www.qtsoftware.com/qt-in-use for a pretty extensive list.

Answer 6

We found Qt to not be robust enough, or functional enough. Too many #ifdef Mac 's/#ifdef Windows needed to be in our code and so we have scrapped all Qt work. It seems like a great idea I just don't think it is there yet. Plus, you have no ability to take advantage of the different platforms real cool GUI abilities. We now run with seperate GUI layers and all of our background classes being C++ that will compile on either.

If you are aiming at Windows and want to be done with MFC, WPF is where you should be looking

Answer 7

Qt is excellent.

I have over 6 years full time development experience in both Qt and more than that with MFC. MFC ties you a single platform. Qt includes many powerful features, for example a WebKit integration.

I have found it to be robust and complete for advanced application development.

Answer 8

Sure Qt doesn't look the same on all platforms, but I thought that was sort of the whole point. Who wants an app that looks the same when the platforms native look and feel is so different. I think that especially on the Mac there's a strong pull towards pixel perfection with the native look and feel, and from what I understand, the Qt guys are putting lots of effort into making it so (with 4.5 I even read they're moving to Cocoa, which should be quite a blessing in these regards). Finally, I personally think it rocks that Qt lets you add ifdefs for platforms. I don't know of any other toolkit that allows you to accurately pinpoint a platform difference in your code by saying #ifdef Q_OS_HPUX or #ifdef Q_OS_MAC. So easy!

Answer 9

Hi

If you don't feel like using qt directly there is also the possibility to use it indirectly with kde4 on windows, one good thing would be that your program could be more OS neutral and maybe more portable?

/Johan

Answer 10

I have been using Qt and PyQt for years on Linux or on Windows (those days, my apps are Windows only). I have been a very very happy user. Qt, especially with the 4 series is a masterpiece. Documentation is excellent, easy of use is very strong, lots of components available for many things. The cross platform aspect is somehow just a minor benefit in comparison of everything else that Qt brought me.

Answer 11

We use Qt for an app that is ported to Linux and Windows and have very few issues. We use quite a number of widgets and several of the utility classes (like QFile, QString, etc.)

We don't use qmake on Windows because of some complexity in our VCproj files that is hard to express in the .pro files, but qmake does the job on Linux.

I can't imagine going back to having to know the native graphics code for the two platforms. Talk about lots of #ifdefs (or separate source files)...

Answer 12

After switching from MFC I do miss trawling through codeproject to find esoteric things like a usable grid control or a color picker.
It also gets a bit tediously boring having a single string type and the classes not being designed by separate teams that obviously hated each other but you get used to that.

You do have to provide set/get methods for the slots rather than just making all your variables public in order to use DDX.

Answer 13

I love Qt. I use it for everything. But if I wasn't familiar with it, and only going to develop on Windows, I'd prolly go with C# .NET. Because Qt isn't quite native. And Qt has compromises in its API for the sake of cross platform development. And C++ applications and additionally Qt applications are not trivial to distribute.

I say probably, because actually, thinking about it, the open sourciness of Qt has saved my arse a few times, and I feel a lot more comfortable working with tools that are open.

Answer 14

I've only recently started with C++ but basically I'm interested in these things:

1. Learning. Duh. I can't write any code if I can't learn it.
2. Portability. I use Windows mostly at work and Linux at home. Most of my friends use Windows either predominantly or exclusively. I know people with Macs. I would like the option of writing code for all of them.
3. Freedom. After trying a number of operating systems and operating system distributions, I've formed the opinion that the Free stuff is of a higher quality. Also I find it more morally acceptable. So I don't want to be restricted (by my library choice) to writing proprietary software.
4. Commercial Might. Freedom. After trying a number of operating systems and operating system distributions, I've formed the opinion that a real quality product forms more readily with strong commercial backing. Red Hat, Novell and Canonical make flavours of Linux that appeal strongly to me - and what do you know, they're commercial vendors. Windows and Mac OS X are (proprietary) commercial operating systems, and they're good enough for most - this only serves to emphasize my point.
5. A simple build process. I come from a scripting background, and I'm accustomed to having my changes applied the moment I hit save in a text editor - not having to compile. So having a very quick and simple build process is important to me. If I can use the same build procedure on multiple platforms (or by flicking a switch on a cross-compiler) I won't feel like I've strayed too far from the scripting world.
6. Object-Oriented Programming (and other "oh look at me I know all the silly compsci 102 buzzwords"). The first language I was really comfortable with is PHP. Now, PHP is quite the powerful object oriented language, BUT most of the examples (and indeed, most of the documentation) completely ignores any Object Oriented features. Believe me when I say, all the facilities for that kind of programming exist in PHP - it's just that unless you're taught it formally, you will learn all the "wrong"/old things first like I did. Basically, I want to be able to participate in Object-Oriented Programming, and I don't mind having to work to figure out how to apply it - in fact, if I get to choose which paradigm I subscribe to, that's even better.

How does Qt stack up?

1. 10/10. It's easier to learn than pure C++. (although you need to learn both to use it properly!)
2. 10/10. I haven't had to do platform detection even once. Ever. I will have to when I finish my current project though, because there will be an option to wake up the display (Windows and Linux only, can't test on a Apple) when certain events occur in the app. But that's arguably pretty low level; you can write a text editor, web browser or game without needing a feature like that. My qmake project files are portable to all platforms without special software (ie without REQUIRING scons, cygwin or msvc, although if I wanted to switch to msvc there would be no problem)
3. 10/10. Qt allows me to release my work under the GNU GPL if I wish, and this makes me happy.
4. 10/10. Qt is backed by Nokia. Everyone knows Nokia. I own a fairly expensive Nokia with a bunch of Qt apps on it. Furthermore other companies like Google, Red Hat et al probably submit the odd patch now and then. You can't get much more commercial than this.
5. 10/10 qmake && make. How hard is that? It works on Linux. It works on Windows. It even works on FreeBSD. I don't have to define anything or rewrite any project files or anything. It's idiotproof and it never goes wrong.
6. 10/10. Although I can't break free of Object Oriented Programming when I use Qt, I can stray pretty far from it before the application falls apart. And when I return, OOP in QT is always waiting with open arms to welcome me back. Frankly, I don't mind having to use Objects of various kinds for everything. No matter what mood I'm in it feels pretty natural under Qt.

Qt overall: 10/10. ... As a C++ newbie, I've never tried another C++ library and I probably never will. I can get everything I need from Qt at this point; even JSON and SOAP and File Locking and ......

I'm quite capable of writing C code and I like plain C a lot. I'm looking into learning about doing GTK+. Not because of any dissatisfaction with Qt; after a bit of soul searching Qt seemed like the obvious choice (I chose the library, not the language - and then started writing it in its native language). No, I want to learn GTK because so many Free Software projects I'm interested in use it, and I'm interested in having the knowledge to contribute to them. Some very interesting projects include browsers and instant messengers (like Pidgin). Networking code is something I'm pretty well familiar with (lots of PHP time) even if it is in totally the wrong language so when some protocol problem happens in a software product I know what it is ;).

No, I've gone way off track now (but I'm retaining the digression). The point is that Qt has everything I was looking for in a library, including portability and a shallow learning curve.

The performance isn't as good as doing native API function calls directly, apparently - but I don't care! It's still VERY quick compared to most scripting languages (PHP is more than fast enough if you write good code and even sometimes if you don't!) and it's still faster than many "proper" programming languages. I'd rather finish the application in one year and have it take an hour to execute, than take ten years to write the same program to do that same job in 45 minutes (unless the slower version is a stepping stone, but bear in mind I'm comparing the abstracted model to the bare API paradigm). For more information about how using a library can make an application faster, more stable and more fun to write, look here.

So for me personally the questions is not "Why switch to Qt?" but "Why move away from Qt?"... And there is absolutely no reason to do so at all. I'm hooked for now. I'll only be working with other systems if I happen to be hacking someone else's project.

Having not used MFC I can't possibly tell you that moving to Qt is the right thing to do, but I tell you: TRY IT. See whether it's difficult to learn to use it. See if it hurts your work in any way. If not, you win. I bet you would win :-P

Answer 15

Qt vs MFC performance