tags:

views:

4699

answers:

15

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).

+3  A: 

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

Paul Dixon
wxWidgets looks *too* MFC-like. I got the feeling it was used primarily as a replacement for people used to MFC, not a first-choice platform. Sure, it'd be easier for me... but I don't feel it is a good fit for me personally.
darron
+4  A: 

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.

signals and slots encourage spagetti code on the other hand. Nevertheless spaggeti are tasty, and most of the time easier than refactors.
Ronny
The documentation for Qt is the best of any programming toolkit I've ever used. So either you were doing it wrong or the MFC docs (which I've never looked at) are bloody amazing.
Max Howell
I've a totally different experience. I've found the documentation to be simply excellent and more complete than any other toolkits. So whole framework is very easy to use thank to signal and slots and this helps in creating clean code. However, there is a clear paradigm shift from MFC
Bluebird75
I also have the complete opposite experience regarding documentation. Qt has simple docs, well laid-out. It takes basically forever to figure out the simplest of systems in MFC, due to the documentation that was vitally important 3-4 compiler versions ago.
jkerian
+30  A: 

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'.

gbjbaanb
There's also a MFC migration framework where you can host MFC controls in QWidgets and vice versa
Henrik Hartz
Qt is 10 times easier to use than MFC. I had reports of teams putting newbie developers on a project with Qt. After one month, they were efficient, and after 3 months, they were completely proficient.
Bluebird75
Mandatory "it's Qt not QT" comment.
Parker
@gbjbaanb, The link "including C#" is broken.
strager
fixed the link - it now points to Qyoto library
gbjbaanb
+8  A: 

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.

Arcane
+15  A: 

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.

Henrik Hartz
VLC also GUI part
yesraaj
Opera is not based on Qt, Opera use Qt on linux in the same way it use windows api on Windows. Opera developed its own lightweight portability layer.
Massimo Fazzolari
@Massimo, that sounds downright pointless to me. I wonder why they don't use Qt everywhere, as it would be far easier than wrapping up every platform's API.
iconiK
A: 

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

Alex
The problem here is you're saying you wrote your own, seperate layers. So, nothing else worked either. What kind of thing did you need to #ifdef all the time? ... I have no problem writing -lots- of code... I currently have my own little framework going. It's just irresponsible of me to use it.
darron
(Irresponsible because nobody knows it but me). I want to avoid .NET, for quite a number of reasons. I use it when required, but I'd rather not. I'm not aiming at Windows in the long or even middle term. That's probably the most relevant reason for this.
darron
Sounds like you might have done something wrong if you had to ifdef all over.. Qt's designed to be cross platform, and as long as you stay with the Qt API you don't need to refactor when migrating to another platform
Henrik Hartz
I feel your pain to some extent, but your alternative sounds ludicrous.
Max Howell
@dblack The ifdef's were for all sorts of things, like a control wouldn't display correctly on both platforms so we would use the control we wanted on the platform it showed up well, and some other control not quite perfect on the one we needed to fudge.
Alex
@dblack continued....other ifdef's were perfectly understandable like where we were doing video rendering and alike. Also like I pointed it out it was just too hard to get things to look good on both platforms, just because it compiles and works doesn't make it right.
Alex
@mxcl -> actually the new way I think works well with the GUI design kits available (WPF expressions blend and I can't remember on the Mac) the gui front ends are much better looking, much more user friendly, aimed at their specific platform and they are easy to maintain.
Alex
@mxcl -> plus the background is probably 80% + of our code and that is pure C++ and very cross platform. Of course we still have ifdef's in here, but they make sense here.
Alex
@henrik- No offense but BS,of course it is designed to be cross platform, that does not mean it looks and performs well on both. You must be using very simple controls on a very siomple lay out if yours looks great on both. Everything from text display differences to different positioning of control
Alex
Given that your experience of requiring #ifdefs and such is fairly unique among the responses, it would have been helpful to give details. "Video and rendering stuff", is completely unhelpful, given that Qt handles video just fine, and you gave no details on the layout issues.
jkerian
+12  A: 

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.

james creasy
+2  A: 

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!

A: 

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

Johan
+4  A: 

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.

Bluebird75
+3  A: 

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)...

Michael Mathews
+3  A: 

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.

Martin Beckett
+5  A: 

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.

Max Howell
+27  A: 

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

+3  A: 

Qt vs MFC performance

Comptrol
your link is now broken
Steve Obbayi
@Steve thanks, I have fixed it.
Comptrol