Stack OverflowQt versus WPF/.NET
[+155] [22] aaronc
[2009-04-28 23:05:13]
[ .net c++ wpf qt mfc ]

My company is trying to make the decision between using Qt/C++ for our GUI framework or migrating to .NET and using WPF. We have up to this point been using MFC. It seems that .NET/WPF is technically the most advanced and feature-rich platform. I do, however, have several concerns. These include:

For this application we are willing to sacrifice support for Windows 2000, Macs, and Linux. But, the issue is more related to Microsoft's commitment to the framework and their existing platforms. It seems like Microsoft has a bad habit of coming up with something new, hyping it for a few years, and then relegating it to the waste-bin essentially abandoning the developers who chose it. First it was MFC and VB6, then Windows Forms, and now there's WPF. Also with .NET, versions of Windows were progressively nicked off the support list. It looks like WPF could be here to stay for a while, but since it's not open source it's really in Microsoft's hands. I'm also concerned about the overhead and performance of WPF since some of our applications involve processing large amounts of information and doing real-time data capture. Qt seems like a really good option, but it doesn't have all the features of WPF/.NET.

Basically, what does the community think about Microsoft's commitment to WPF compared with previous frameworks? Are the performance considerations significant enough to avoid using it for a realtime application? And, how significant are the benefits of WPF/.NET in terms of productivity and features compared to Qt?

(4) Don't forget WPF is single-buffered on WinXP, so your best choice of OS is Vista and Win7 (if you go WPF way). - alxx
(5) WinForms have been thrown to the waste-bin ? First news... The framework (.net 2) is totally mature (so do not need much more improvement), and Microsoft continues to ship it with every version of windows. You have something robust to develop with, why do you call it dead ? - Aurélien Ribon
(1) True, how can you say WinForms is nicked . It is NOT, theres a wealth of community info, tons of apps already built and lots of devs still using win forms 2.0. And with C# 3 you get Linq!! It just keeps getting better. Also, .Net is large Eco System (web apps, silverlight, mobile apps, XNA, theres even .Net Micro Framework) MS has to have commitment to it. - gideon
@gideon: Take a look at this for Sliverlight: - Ako
(2) Except for longevity I don't know that I'd compare MFC to VB6. MFC is still going strong and is supported well enough and actively extended. Given that it's a collection of wrappers around the underlying win32 api (which isn't going away anytime soon) and more recent features (like the ribbon ui) are generally available in MFC before .Net. I you're doing desktop work I'd look strongly at QT or MFC, and for commercial work MFC doesn't the license or cost of QT. - nerraga
Funny in retrospective: Winforms 2.0 and .NET 2.0 had been dropped in current pair of user and server windows. And 3.5 is problematic at least. - IBr
[+140] [2009-04-29 15:48:44] Alan

If future proofing your system is a major concern then I would seriously consider developing using the Qt framework.

It uses a modern approach to C++ interface development (compared to the MFC) and has the additional wow factor of being cross-platform (Apple/Linux popularity is continuing to grow).

With Nokia's backing, you can also expect good support for hand held devices - again, an industry that's growing rapidly.

I don't think C#/.Net will be going away any time soon, however a lot of people have been predicting C++'s demise for years now and it's still going strong.

(3) +1 to the handlhelds, that's THE major growth area for the moment, and should become ever more important in the future. - gbjbaanb
(23) -1. C++ is not "still going strong". The number of C++ programming jobs has halved in recent years whereas C# has tripled: - Jon Harrop
(76) And the number of Haskell jobs has gone up 2000%, from 1 to 20. All the crappy entry level Java jobs have now become crappy entry level C# jobs - yay for them - Martin Beckett
(1) Also with regards to future proofing; Qt is available under the LGPL, so if Nokia should decide to discontinue the project some time in the future, the source code is still available and a community will be able to keep it alive and/or help with transitioning away from it. - Magnus Hoff
(14) 1. WPF is also cross-platform: Silverlight runs on Windows/MacOS/Linux, several handheld OSes, and is being ported to more as we speak. 2. C++ developer productivity is significantly lower than with C# because C++ lacks many advanced features such as LINQ, properties, events, and garbage collection. 3. Microsoft's commitment to backward compatibility is legendary. Windows 7 runs DOS programs written almost 30 years ago. There are DOS, Windows 1.x, 2.x, 3.x, etc, emulators for every major OS. If you stay within the API, your C#/WPF app will probably run perfectly well in the year 2100. - Ray Burns
(3) MS has stopped doing backwards compatibility recently - when the new C# APIs arrives, backwards-compat became less of an issue. As for C++ jobs.. there's less VB jobs too but you might have noticed C++ jobs pay more than C#, get your priorities right :) - gbjbaanb
(21) Qt has properties, events, foreach loops and plenty of other features added on top of vanilla C++ too. Qt's QObject system also makes a lot of memory management of Qt objects automatic. Basically, C# may have better productivity than C++, but productivity of Qt C++ is greater than plain old C++ too (not quite as much as C#, but still a mentionable amount) - Dan
(32) Ray, WPF is not a cross platform. It's windows only. MoonLight is alpha product. - Zuuum
(2) -1, Nokia's deal with MS puts the future of Qt in question. - Mas
Also you use c# to program windows phones - Kugel
@Mas True, but it's easy to predict the past from the future. - kenny
(3) @RayBurns MoonLight is discontinued because Silverlight holds 0.2%, yes, 0.2%(Flash 23%) of the market and no one is interested in supporting it. And here is a link to read about it(Cause C# fans love to troll):… - Lilian A. Moraru
(1) "With Nokia's backing". Nokia sold Qt to Digia Oyj at a huge loss.… - Jon Harrop
Using WPF from F# is easy. Using Qt from OCaml is ridiculously hard. - Jon Harrop
@Alan It has been more than 3 years since this question was first answered. Since then Qt has been abandoned by Nokia and now rests with Digia. Does your stand for Qt still hold ? - Wildling
[+89] [2010-01-13 14:26:37] CMircea

The GNU LGPL does not force you to share any code, not even when static linking. It is a common belief - you just have to provide a way for the user to link their own copy of Qt with your application and debug it; DLLs already provide this, with static linking you can provide object files.

Qt provides EXTENSIVE features for all supported platforms. The biggest that come to my mind are Qt Concurrent and threading APIs, WebKit, Qt Script and of course, Qt GUI. The fact that C++ is dying is because most people think of C++ as the crap code floating around written using only native low-level APIs, MFC or similar libraries/tools. Qt is a modern and stable development framework that's been around for a really long time. Nokia did not acquire it just for their devices, since their devices are just NOT POWERFUL enough to handle the advanced Qt features, notably Qt WebKit - WebKit itself is really a hog and is not targeted towards embedded development.

Qt is consistently getting more features. For example 4.5 brought a Cocoa port, XSLT, ODF. It also brought a new raster engine that is, get this, STUPIDLY FAST, as well as an OpenGL (ES) 2.0 engine for hardware accelerated graphics. 4.6 has brought an animation framework, a state machine, and an EXTREMELY fast JavaScript engine inherited from WebKit, for WebKit itself and Qt Script - SquirrelFish Extreme is currently the fasted JavaScript engine, beating Chrome's V8; 4.7 brings Qt's version of WPF, called Qt Quick, with a declarative language (QML, based on JavaScript), QtDeclarative module (which integrates with the Graphics View framework and has APIs to bind custom C++ objects to QML), extended networking APIs and improvements to the WebKit module (and updated WebKit code).

What does WPF provide as a browser widget? Trident. Thank you very much, right now Trident is one of the slowest engines in all aspects, though I hear that work is in progress to dramatically improve performance. All a good choice to shoot yourself in the foot when you want to port your software to another program, especially the rapidly growing market of embedded devices - you are basically locked to Windows CE/Mobile, whereas Qt has been ported to Windows CE/Mobile, Embedded Linux, Symbian S60 and Maemo is coming soon. Qt has the most extensive platform support I've seen - see the list in the Qt documentation [1].

Even though Qt provides some very high-level APIs, it is VERY fast, and when speed is critical, it allows you to go as low-level as you want, potentially even assembly. Alien widgets provide flicker-less fast rendering, however, you are free to request a native widget - just set a flag. For concurrent programming you have threading primitives like mutex, read-write lock, wait conditions, semaphores, as well gradually higher-level APIS - thread pools for example, ending with Qt Concurrent. Signals and slots are an invaluable way to pass data between objects in a thread-safe manner without any locking, relying on the event loop to safely deliver all events and signals.

Qt is extensible as hell. You can subclass practically all classes, and if that way you are unable to perform an operation, you are provided with full source code for all platforms and rights to modify it to your needs on all licensing options. Furthermore, Qt guarantees backwards binary compatibility across minor versions and forwards AND backwards binary compatibility across patch versions (of course, code depending on a fixed bug will not work on versions with the bug; X.Y.Z --> X = major; Y = minor; Z = patch). Tools are also provided to gracefully move to major revisions at your own pace: Qt 4 includes a tool to migrate Qt 3 code to Qt 4 code AND a Qt 3 support module, implementing the whole Qt 3 API (unless the Qt 4 version of the class is fully compatible with the old one), thus your old code is always safe.

I argue that Qt is an application development framework, unlike WPF which is just a GUI part of .NET. Qt includes many non-GUI modules: Core, Network, SQL, XML, Script, and more. All provide both low-level APIs (QIODevice, QTcpSocket) and high-level APIs (QTextStream, QNetworkAccessManager). The documentation is a subjective part, but in my opinion I believe that it is very good and extensive, and when the documentation is not enough, the community is always there to help, as well as Nokia's support contracts.

P.S.: I do not have any .NET experience, I have just stated why I believe Qt is often a much better choice over .NET. There are exceptions to everything and .NET excels in many areas as well; nothing is perfect, you have to pick the right tool for the job. I have tried to list all the advantages of Qt I can think of and why it is a great toolkit. Please consult the Qt documentation at for all the details and remember than Qt is a toolkit, it includes several tools: Qt Creator (IDE), Qt Designer (GUI designer), qmake (build system), Qt Linguist (translator) to name a few.


(40) +1 for pointing out that Qt is actually an application framework, not only a GUI framework - Frank
(2) @Novos and now with 4.7 it has an equivalent of WPF in the form of Qt Quick. - CMircea
(7) WPF is just a part of .NET. And you would argue that .NET is not an application framework ? Network, SQL, XML...everything is also in .NET, so what is the difference ? - Aurélien Ribon
(7) @Aurélien, I know that, but aaronc thought Qt was just a GUI library, so I had to clarify that Qt is an application framework as well. - CMircea
(1) "I do not have any .NET experience, I have just stated why I believe Qt is often a much better choice over .NET". If you have no experience of one then you are not in a position to compare them. FWIW, I have experience of both and the biggest thing that leaps out at me is your use of "high-level". Not many people regard a text stream as a high-level API these days (!). - Jon Harrop
+1....for exhausting Qt features... - Beagle Bone
[+61] [2009-09-01 16:44:59] gbc

Two years ago I was migrating a Visual Basic 6 [1] application and had to decide between Qt and WPF. If I had chosen Qt, it would have been working with Python and the PyQt bindings. After working with both for a month, I ended up choosing WPF because of licensing costs. At the time, Qt only offered GPL or a paid commercial license (which was fairly expensive) and the PyQt license was an additional cost. With an LGPL option for the Qt license, the decision would have been different.

In terms of speed, I have found both Qt and WPF fast enough and from an end-user perspective there was no perceptible reason to favor one over the other.

Qt with PyQt was a very productive and fun way to build applications. The Qt libraries are very well thought out and have the feel of code that has been polished over a long time of real-world use, which makes sense given its history. The documentation is good, though tool support wasn't nearly as nice as Visual Studio (when using PyQt, I can't speak for C++), but having well thought-out libraries and a concise language eliminates a lot of the need for fancier tools.

Unlike some of the other comments, I found WPF to be fun to use as well. The declarative binding between your business logic and presentation templates reduces a lot of boilerplate code and allows for clean separation between model and view. It has some nifty features like thread-safe binding and a simple-to-use 3D library. On the other hand, Qt can match these features and it is cross-platform. Furthermore, WPF does have some rough edges and the documentation can be sparse, a lot of answers to quirks can only be found in the sea of blog posts and forum comments.

Given the change in licensing terms, if I had to make the same choice today, I would move forward with Qt (and Python for me because I'm not enough of a hero to write in C++). But, WPF is treating us well and still a pleasure to work with, so I can't say it's a bad choice.


(4) You may think of using IronPython with WPF now. - Gulshan
(16) +1. It would be great if more people speak from real world experience like you instead of speculations. - kizzx2
(1) [Gulshan] "You may think of using IronPython with WPF now." - unfortunately Visual Studio only seems to properly support it with C#. - Cornelius Scarabeus
(1) "On the other hand, Qt can match these features and it is cross-platform." - Any way you can do MVVM with Qt? That's something I'm missing from WPF now that I'm working with Qt (PySide). I've asked a question about this:… - Jorge Vargas
I would choose Qt not even for Qt itself but to avoid Visual Basic at all cost. And if the alternative was Python... I would pay from my salary to crucify Visual Basic. Terrible language. - doc
"unfortunately Visual Studio only seems to properly support it with C#". I've been writing commercial software using WPF from F# for several years now and haven't noticed that problem. - Jon Harrop
[+46] [2009-04-28 23:44:59] KeyserSoze

There are Qt bindings for Python, C#, Ruby, Java, Ada, Pascal, Perl, PHP, and Haskell [1], however, they aren't supported by Trolltech (or now Nokia), and I've no idea if they work well at all.

Even so, I'd rather use C++ with Qt, than whatever microsoft is pushing right now. You can run Qt on every popular desktop OS, and with the licensing terms, even if Nokia goes bankrupt or sells Qt off, you've got all the source code. You can maintain it yourself if you need to, and modify it however you like, you just need to make your source code modifications to the Qt libraries available to anyone you give binaries to.


(2) As far as I know, the Qt binding for Java ,called Jambi, is supported by Nokia. - Lucas
(3) The Python bindings are very good, and they're commercially supported by a third-party company, but they're GPL (with commercial licensing available) rather than LGPL. - Josh Kelley
(1) Jambi has been discontinued - see - Pavel Minaev
(11) There's a new set of Python bindings, PySide, that are LGPL. - KeyserSoze
(1) True, Jambi won't be maintained after May 2010. However, as your link indicates, the code is LGPL so you can maintain it yourself, and it is still available for download from Nokia. That's a much better situation than if a closed-source toolkit you depend is discontinued. - KeyserSoze
(24) -1. Most of those "bindings" are toys with no serious users. The idea that being able to maintain Qt yourself is an advantage is absurd. - Jon Harrop
(7) The pyside bindings are supported by nokia. - Roman A. Taycher
@JonHarrop maybe not literally yourself but Qt has huge community and tremendous user base in industry and open source world. Also major Linux desktop environment KDE depends on Qt and in fact developers of KDE already play active role in Qt development. - doc
"Qt has huge community and tremendous user base in industry and open source world". The three most popular desktops in the world are Microsoft Windows, Apple Mac OS X and Canonical Ubuntu and none of them use Qt or KDE. The only places Linux has gained traction are supercomputers and Android mobile devices, neither of which use Qt or KDE. - Jon Harrop
"Major Linux desktop environment" - That's an oxymoron if ever I've heard one. - John Reynolds
[+37] [2009-05-17 19:13:36] Kensai

Reading your concerns in your initial post, aaronc, I have to say that you almost answer the question for yourself. The right way to go is definitely Qt.

This past year has been a real revolution for Qt. First the Nokia acquisition of Trolltech (securing development funds for years to come...), then the new license (LGPL), and last but not least the complete opening of the source code and the friendly approach to a democratic roadmap.

I don't want to imply they are saints, Qt Software is a for-profit company as well. Neverthess they invest heavily into new easy tools that are code-proof for future cross-platform porting. Have you seen the new Qt Creator [1]? Simply amazing.

The Qt toolkit is very strong and they enrich it continuously. Check out the new Embedded Widget Demos [2] and the Declarative UI [3]. This way you are even covered for WPF-like stuff.

So my advice is Qt all the way...

Good luck!


(7) -1. No mention of Qts recent troubles (e.g. Nokia dropping Jambi) or any of WPF's major advantages of Qt. Indeed, no technical information about WPF at all. - Jon Harrop
(20) @Jon Harrop, why does every answer have to discuss both? Each poster can only write about what they know. It's up to aaronc to review posts discussing both sides, and decide. - Yawar
(1) Two of the links in this answer ("QT Creator" and "Embedded Widget Demos") are to, which now redirects to, a German company that has nothing to do with Qt. - RenniePet
"the Nokia acquisition of Trolltech (securing development funds for years to come...)". Less than four years later and Nokia just sold Qt off at a loss to Digia Oyj (who are posting heavy losses). - Jon Harrop
[+24] [2009-06-13 12:49:40] Sharique

There are a few points worth considering before making any decision

  • Qt is much faster than WPF. I don't think WPF can match its speed.
  • Qt style is the same as CSS, so you don't have to learn new things. In case of WPF, it is quite complicated.
  • Qt has an animation framework (currently as a separate project), WPF uses DirectX for animation.
  • Qt is cross platform, WPF is Windows-only, there is no WPF implementation open source (Mono does not have WPF implementation).
  • Qt uses OpenGL for rendering which multi-platform hence easy to port applications to other platforms.
  • WPF have very good support for data binding, Qt data binding is nowhere near to it.

You can use Qt with C#, either Qyoto or QT4dotnet [1].

There are a lot of things in Qt roadmap [2] which look very promising, have a look at them, before you decide.


(16) -1. "Qt is faster" at what? citations? "Qt is easier": not IME. "WPF has DirectX" is just nonsense. WPF provides its own integrated 2D and 3D vector graphics with effects. - Jon Harrop
(1) WPF is also cross-platform: You're forgetting Silverlight, a cross-platform implementation of a WPF subset that runs on Windows, Linux, MacOS, and some mobile devices. Silverlight currently has more capabilities than Qt even though it is much younger. And the gap is widening. - Ray Burns
(4) @Ray: which capabilities are these? Be specific please, otherwise your comment doesn't really contribute much. What capabilities does WPF have that Qt doesn't? And if, as you say, Silverlight is a subset of WPF, then WPF itself is not cross-platform. - jalf
(10) Where shall I start? Ubiquitous animation (Everything is animatable), Advanced binding (bind to arbitrary objects in complex ways), Better transforms, Shaders, View models, Easy machine-translation of XAML, ControlTemplates, DataTemplates, Fully customizable controls such as ItemsControl, Attached & inherited properties, Easier & more flexible layout, Bidirectional conversion between source code & object model. Much, much more. All of this is in Silverlight, aka WPF/e. The Windows version of WPF has even more and includes Windows-specific stuff. Qt capabilities also vary by platform. - Ray Burns
Biggest difference for me is programming language. Nobody has been able to write OCaml bindings for Qt because C++ is so hard to interoperate with whereas WPF is directly accessible from any .NET language including F#. - Jon Harrop
[+17] [2011-12-01 08:38:48] S.M.Mousavi

Please note i am a WPF Programmer. Therefore i can say you WPF details not QtQuick


Qt/.Net are:

  • Qt uses C++ much more difficult to use than C#. But you can use C# plug-in of Qt
  • Qt is great cross-platform framework in the world. (Windows, Linux, MAC, Phone OSes such as Symbian, Meego, Windows Phone, iPhone and Android now!)
  • .Net is more organized than Qt. It is simpler to use
  • .Net threading is not good as Qt (i think).
  • Qt is more backward compatible than .Net. you can run so much old application with new version of framework
  • Qt is implemented for embedded device and therefore it should use resources better (i think)
  • In any framework, it is require an installed framework on target machine. .Net is more popular in Windows
  • .Net is close source and you must wait for next release for some bug fixes. Qt is open source and you can fix some bugs if you want
  • .Net published under CopyRight license. Qt published under Commercial, LGPL, GPL license.


  • Visual Studio is a great IDE. (most great IDE on the world i think). It has some feature for detail debugging and deploying install package. Qt has great IDE named QtCreator but is not great as VS. You can use VS for Qt within plugin. Qt has not tools for deploying setup package for Linux, Windows, Mac... but it can create setup for Meego and Symbian.
  • Qt has some tools for simpler localization and translate. .Net missing it
  • Visual Studio has simpler visual designer than Qt Designer. For WPF, there is a new tool named Expression Blend
  • There is much Setup and deployment tools for Visual Studio and


  • Great for MVVM pattern
  • Hardware accelerated (QML with using OpenGL for Windows, MAC, Linux and Phone OSes... XAML with using DirectX for Windows and its phone version)
  • Closer to artists
  • You can create a GREAT and NICE UI using XAML/QML
  • Easier UI implementation
  • Nice animation is possible
  • In XAML, usually you can create a Silverlight version of your application just with a little changes
  • In XAML there is some great features such as Template, Trigger (DataTrigger, Trigger, EventTrigger), Binding (in any side and also both side together), Resource, Commands, DependencyProperty and Notifiable Properties.

BUT... WPF is NOT COMPLETE now. It has some mistakes and weaknesses (As i mentioned earlier, I am a WPF programmer and a can say you just WPF details not QtQuick detailes)

  • XAML debugging is not possible
  • For any change in XAML, all program must be recompile

  • Be more careful for performance. For example if you use much many RoutedCommands in XAML, your application will be unusable!

  • In XAML, some feature not works as expected. There is unfortunately some tricks. (It should be clear... should works as expected... isn't it? )

  • Be careful for some similar namespaces like BitmapEffect and Effect. There is different features and costs. (e.g. BitmapEffect has some effects with software render and Effect has some effect with hardware render)

  • In real world, artists could not use WPF as Flash (at least with good performance).

  • Some features works on special places. For example DataTrigger works just in Style tag not in Resource section.

  • There is some weaknesses in XAML. Some examples: there is not any sequential animation... you cannot do any calculation in XAML (you must write a converter in C# even for a liiiittle work! JavaSript is a great replacement in QML)... some attributes are duplicate. e.g. x:Name and Name... Controlling View from ViewModel is not clear. e.g. closing View from ViewModel (you need some CodeBehind)

  • Tooooooo much run-time errors. If you use some tags in bad place it will notice you for syntax error, but many of errors occurs just in the run-time. e.g. if i target Background property (instead of Background.Color) for ColorAnimation, it will compile successfully, but in running animation... BUMP... runtime error!!! in such case on Expression Blend, application will crash!!!

  • WPF are hardware accelerated but not in any hardware configuration. It requires a Graphic accelerator with supporting DirectX 9.0c for full hardware accelerator.

Good luck - S.M.Mousavi

(1) ".Net threading is not good as Qt". I'd have said the opposite. Multithreading is a nightmare in C++ but it is easy for me using WPF from F#. I can do explicit message passing using union types with clear logic using pattern matching and concurrency using asynchronous agents, none of which exist in Qt or C++. - Jon Harrop
(1) I agree with @JonHarrop. Further, "Qt is more backward compatible than .Net". I don't know of ANY code written for .NET 1.0 that does NOT compile on .NET 4. Do you? We're talking about a timespan between the two versions of almost 12 years. See also discussion:… - taoufik
Also, ".NET is closed source" - See website: - taoufik
[+16] [2009-05-13 21:59:20] Piotr Dobrogost

Declarative UI [1] is Qt answer to WPF. Looks very promising.


(1) You probably mean "XAML" and not "WPF" there. WPF is a lot more than just XAML. I write commercial software using WPF from F#. I have concurrent GC, first-class functions, first-class events, task parallelism, agent-based concurrency, union types and pattern matching, type inference, language integrated query... not just in the UI code but everywhere. - Jon Harrop
[+14] [2009-09-02 22:33:11]

Another thing you might want to consider is the availability of third-party controls (widgets) for the frameworks you are choosing between.

For WPF you already have many custom controls available (commercial and not) to extend your applications. Even if WPF is a relatively new technology compared to Windows Forms.

Oh, and the same applies to custom styles/themes.

I'm not very knowledgeable about Qt, but when I was evaluating it a few months ago I couldn't find much in either department.

[+12] [2011-07-01 19:34:18]

Having worked on Qt for the past few months I can say that-

  • Qt is very speed and memory optimized. There are tiny things here are there that are optimized so well that you really wonder how they released Qt on time.
  • Qt is very well documented. Way better than .net. There are examples/sample included and the documentation includes small hacks that are possible to make things run even faster.
  • Qt has a relatively smaller memory footprint.
  • Qt is Multiplatform with the possibility to even run on phones and on Android. Binaries are compiled in the native form to ensure speed ie. no intepretor or jit.
  • Qt tools are great and easy to use, GUI tools especially.
  • Qt is open source meaning it will live for ever as long as there is momentum. While Microsoft may discontinue a product at any time without any notice. I still have a lot of code written in vb6 that I can't port over to .net

I'd say use Qt, its a much better framework with respect to speed, stability, support and framework longevity Apps like google earth, gtalk and picasa, CAD, all KDE apps use qt. I'd say its a safe bet.

[+11] [2009-04-28 23:32:38] landyman

If your application is only going be for Windows, then using WPF or Windows Forms is fine. There are a lot of 3rd party applications for Windows Forms to enhance them a bit if they aren't flexible enough.

Windows Forms hasn't been abandoned by any means -- so using that or WPF, even for a long term release of software should be OK. I would use WPF though, just in case a new feature comes out for it that you would like to use in your application. With Windows Forms, I don't think any new features are planned, so if you go that route, you're stuck there.

I've also messed with Qt and wxWidgets a bit. I like both, but the key feature you would get with both of these is that they are compatible on more than just Windows. The license agreements for both make them attractive for commercial applications too now that Qt has adopted the LGPL license. The communities for both seem good and I don't see development on either platform slowing down at all; in fact, they both seem to be getting stronger.

So what about the feature set of Qt compared to WinForms/WPF? Performance issues? - aaronc
Qt adopted an LGPL license, not BSD - Chris Cameron
Corrected that one. - Mihai Limbășan
my bad on the license -- too many to remember which company adopts which. thanks for the edit. - landyman
@aaronc - I can't speak to the full feature set, but I've found Qt, wxWidgets and WPF to have everything I've needed for my projects. which, admittedly, have been fairly straight forward. I haven't noticed any performance issues when using Qt. Qt is used in Google Earth and Skype, as an example. - landyman
@landyman - and what about performance of WPF/WinForms as opposed to Qt since you've used them both? My concern with WPF is that it needing to tune it for performance will take away from its so-called productivity benefits. - aaronc
(1) @aaronc - I haven't written an application in Qt and the same application in WPF, so I don't have a direct comparison. But, for my projects, it seems like I spend a little less time playing with Qt than I do trying to get WPF/WinForms the way I want. - landyman
[+11] [2009-09-01 16:14:19] Troy Bergstro

I haven't used QT, but I don't like WPF very much. Yes, it results in a very beautiful end product, but at the expense of a fairly agonizing development process.

The Visual Studio WPF designer ("Cider") seems to have been intentionally lobotomized to steer buyers toward "Expression Blend." For example, it doesn't support preview of anything in a Viewbox, but a simple hack (creating one's own user control to wrap the Viewbox) allows the designer to work correctly! The only "problem" here is that Microsoft doesn't want their designer to be too useful and they intentionally removed functionality from it.

This is pure bait-and-switch, the kind of thing you'd expect from a low-life stereo salesman. You can argue technical merits all day (and WPF fails in this regard as well) but the way its marketed is well nigh unethical.

Another thing that I dislike about WPF is this claim that its got some monopoly on hardware acceleration. Anyone old enough to remember the "Windows accelerator" cards of the 1990s should see right through this... the express purpose of these accelerators (now present on any PC) was to offload Windows rendering to hardware. In particular, these efforts were directed at speeding up GDI32.DLL and the GUI portions of USER32.DLL. You can quibble over the nature of the interface, but to claim that the GUI pre-WPF was somehow "rendered in software" is just incorrect.

I don't know if Microsoft ever made this claim, but during the hype period before WPF was actually released (or escaped ;), I heard people claim that in Windows Vista, GDI, DirectX, etc. would simply be wrappers for (the now native) WPF. In actual fact, WPF calls have to traverse a CPU-melting series of wrapper functions (many of which have names reminiscent of ASP.NET) to get anywhere near the hardware.

I take issue as well with the way Microsoft is attempting to redefine the software engineering process via WPF. They are putting forward a vision where graphic artists lay out the UI in Expression Blend before coding begins. I think they're dead wrong about how WPF affects the role of a designer. In my experience, the capabilities of WPF liberate me from the need to consult a designer. WPF has built-in support for all sorts of things (gradients, alpha) that previously would have sent me scrambling for help from someone with a copy of PhotoShop.

Finally, I just don't find WPF pleasant to use. It feels like a step backward from, say, WinForms in almost every way: performance, price (remember, you're supposed to buy Blend and hire an artist), time-to-market, compatibility, etc. The only area I've found it superior is in producing a superficially more beautiful GUI.

FWIW, I've had a lot of success writing GUI apps using WPF directly from F# without XAML. F# is as declarative as XAML but also completely type safe. - Jon Harrop
Although some of your points agreeable, isn't more beautiful and flexible GUI the main objective of any GUI framework? In my experience, WPF application is a lot easier to maintain and modify than Winform or Qt applications. Furthermore, Expression Blend is now included with Visual Studio. - Tae-Sung Shin
[+9] [2009-04-28 23:12:48] David Brown

Windows Forms has not been abandoned. Far from it, actually. WPF is simply an alternative framework for easily building visually compelling applications. I also don't see WPF disappearing any time soon.

As for Qt, I haven't messed with it, so I can't really give you an opinion.

(1) Is Microsoft planning on actually improving Windows Forms? It seems like most new development will go to WPF. - aaronc
Windows Forms will not have any new features from Microsoft from here out. At this time, they are not planning to retire it, but they are encouraging new GUI development to occur on the WPF platform. - MedicineMan
(2) There are plenty of 3rd party developers still in the game. Why do any enhancements to WinForms have to come from Microsoft? - Robert Kozak
(7) There is nothing to improve in Windows Forms. It was good 10 years ago and will work at least 5 more. Bug fixes always appearing and will for some time. WPF is new concept with the idea of markup, cascase styles and DirectX use inside. Just understand that right now Win Forms is mainstream on Win platform and WPF is Next Architecture GUI Framework. - Mash
That being said, what justifies doing new development in Win Forms if the next gen tool is already out? I don't see Windows 2000 support as a good enough reason. - aaronc
Win Forms still mainstream and WPF still in childhood. Anyway - test it yourself to have proper decision. - Mash
What is there to "improve" for WindowsForms? I asked a similar question and after a lot of thought, I realized that it's already very mature. - Rhubarb
WPF is still in childhood but might not make it to adulthood. If the web and mobile is the future then Silverlight might get more of the MS focus. - Martin Beckett
@Mash "There is nothing to improve in Windows Forms" - with that I cannot agree; I believe there is plenty of room for improvements in WinForms, and having a large code base utilizing it I am rather disappointed by its abandonment by MS. - Eyvind
what to impruve in WinForms? background transparency. It's not there. - Luka Ramishvili
People here argue between WPF and Qt features as GUIs. Does WinForms have all of these features? No, it doesn't. So the improvement means adding more useful features that it doesn't have already. I don't mean that they will or should be added. - Luka Ramishvili
[+7] [2009-08-13 14:16:21] John

Warren Buffett [1]'s strategy/wisdom to pick stocks fits very well to choose WPF vs Qt.

One of his favorite picks is Coke Cola. Why? Coke Cola NEVER changes, need no new investment to innovate the product to make money.

Windows changes too much and too quick. You really need a very stable programming language to make a really good product in long term. C#/WPF is definitely not the long term stable programming language, while Qt has proven itself for longevity since 1991.


(3) not really... the current release it QT4... the "4" in the name should say womething:) - Quamis
(7) GDI/GDI+/MFC/Winforms/WPF/Silverlight/DirectShow/DirectDraw/Direct3d/XNA and now Direct2d. Qt may have 4 revisions to a single API, but that hardly counts as unstable. - gbjbaanb
(2) I wouldn't agree with you comparing coca cola to software development. Coca cola is a product with some secret ingredients, protected by patents and has a big marketing campaign behind it, with some loyal consumers... therefore, a very inelastic product. - taoufik
(4) The software market has much faster moving cycles, open for innovations and highly competitive. Therefore, if you'd stick with 'proven technology' from 20 years ago and not respond to the trends, there is a high chance you're going to loose market share on the long term. The software market is much more elastic, with minimal/no loyal consumers. To make it worse, consumers get bored easily with software, and we as developers should expect them to embrace new concepts. - taoufik
(6) @gbjbaanb: DirectShow, DirectDraw, Direct3D, Direct2D and XNA complement each other and are not in any respect high level GUI frameworks like Qt or WPF. GDI+ is just an updated GDI; both MFC and Winforms use GDI for low-level drawing. And Silverlight is simply a slimmed down .NET-framework + parts of WPF. There have been a lot less transitions than you try to suggest with your list, it's essentially MFC -> WinForms -> WPF over the last ~ 18 years. The indermediary WinForms was probably unnecessary, true, but the switch from MFC to a managed high-level GUI framework (WPF) seems sensible to me. - Frank
@Novox: MFC was just a wrapper over win32 GUI, so perhaps we should discount that too? If you only want a editbox and a button, you're good - but that isn't the whole of GUI development. WPF after all, tries to deliver many non-form elements that would be addressed by lower level older APIs. - gbjbaanb
Win16/32 is what is called a "personality" of NT (and the native API of older versions of Windows), but not a GUI framework. Of course MFC had to built ontop of Win32. Still I don't see the point you're trying to make. - Frank
The Coca-Cola company and its products as an analogy for software development companies and their products is poor for several reasons. The core compentence at the Coca-Cola company is marketing, not soft drink production. Any idiot can manufacture the soft drinks, and a lot of the bottling operations are franchised. - RenniePet
Hmmm... new features on same base looks very interesting. I want to upgrade my code to use new features, this is not possible on .NET easily. Is this possible on Qt? - S.M.Mousavi
[+6] [2010-08-02 01:17:46] user408209

Qt is really fast. So if you want the best performance and are willing to live without garbage collection and a larger class library, go with Qt.

Qt has a nice way of hooking up events using Ports, but there is a preprocessor called the Meta Object Compiler that gets run on your source code. It's so fast that you won't notice a delay in compilation, but you should be aware that it does require this extra level of complexity, in that the auto-generated makefiles build "moc_"... files for each of your classes that derive from QObject, and the debugger traces through them when messages are being sent. It's an elegant system, though, if you want maximum execution speed with your flexibility, since this is compiled C++, not interpreted C# (through the CLR).

On the other hand, WPF can be more productive, once you put in the effort to learn its way of doing things. And yes, it's plenty fast enough for most applications. For a true "real-time" system, C++ will give you better predictability, but you'll want to consider the OS you're running on, not just the language you're using to implement the app.

(3) C# code (and any other CIL assembly) is not interpreted if run on the CLR (and on Mono), but JIT compiled to machine code. - Frank
[+6] [2010-11-08 10:15:17] Ramesh Kasi

I have good experience in MFC, Qt and C#/WPF.

Go for Qt, If you want to develop an application with better performance, Cross platform support(window, MAC, Linux ) and better QUi feature.

Learning point of view, a developer can learn Qt quickly comparing with C#/WPF.

QT Licensing cost is bit higher than C#/WPF, I guess not very sure.

Go for WPF, If you want to develop an application very rich QUI, good performance, and only windows support.

[+5] [2010-01-09 01:42:20] Paul Jurczak

Since you mentioned real-time data capture, you have to be very careful with .NET, which is running on top of garbage collected runtime. I don't think there is a guarantee of upper latency limit, if you develop in managed code. You will have to cross to native code or use 3rd party products to guarantee capture of all your real-time events.

(2) The .NET GC is concurrent so you just need to make sure any soft-realtime threads do not allocate heavily and they will never be stalled for a significant amount of time. - Jon Harrop
(1) In real-time data capture scenario, "never be stalled for a significant amount of time" may not be good enough. You may need strict guarantees of maximum latency, say 10us. I'm a little bit skeptical whether .NET GC can provide them. - Paul Jurczak
(7) If you need strict guarantees of maximum latency measured in microseconds, you need to consider very carefully whether a general-purpose computer system can provide them no matter what language you use, or whether you need a real-time operating system. It's been a long time since you had full control of the hardware on a standard PC even programming in assembler. - rwallace
@PaulJurczak "guarantees of maximum latency, say 10us". That is way beyond the capabilities of any general purpose operating system, much less garbage collector. - Jon Harrop
[+5] [2010-09-04 17:29:12] kenny

I think MS's commitment to WPF was shown by rewriting much of VS2010 in it. You can't get much more than an endorsement. My experience with WPF is very good as well, it's pretty well thought out.

(2) Unfortunately, VS2010 is hardly a shining beacon of WPF's superiority. It is sloooow and sluggish, even more so than VS2k8. - jalf
(1) I agree about 10 being a pig, certainly rushed out. - kenny
I recall it mostly be because it's not at all rewritten, just parts of it, and the interop calls takes away all the possibility of a performance increase for now? - Oskar Duveborn
(4) SLow, slow... Launching Netbeans or Eclipse will tell you what is a slow start for an IDE. - Aurélien Ribon
(3) @Aurelien Eclipse launches for me about in same speed as VS2008, and including project open time in VS, Eclipse loads faster than VS2008. I use both IDE's and I should say they are of about the same speed, with one shining over another in certain areas. e.g. Visual C++ takes more time to compile C++ code than GCC (used by default by Eclipse CDT, so with Eclipse you get less launch waiting time.) but VS shines over Eclipse in many areas :) - Luka Ramishvili
VS2010 is slower than I'd like but VS2012 fixed the pain points for me. What I find interesting, however, is that I have never seen a Qt app that looks or feels as good as VS2010. I used KDE for many years under Linux and it was good for its time but remained stuck in the 1990s. - Jon Harrop
[+3] [2010-10-16 21:36:02] Potato

Qt will definitely become the de facto framwork to use on any linux bases OSes. Mono simply does not provide enough compatitiblity to .NET and also WPF cannot be directly ported over to linux because it uses DirectX as it rendering API.There is nothing wrong in staying with C++/Qt if cross platform compatibility is needed. But if you only intend to target Windows and your application is not graphically intensive (like 3D rendering or Games) WPF/C# is the way to go.

[+1] [2010-09-04 17:17:03] dmihailescu

I don't see how QT will become more popular than MFC. There is another framework called WTL that did not gain much traction. I see MFC losing ground to Forms and WPF despite some performance issues of the latter two. Check:

"I don't see how QT will become more popular than MFC". Qt is open source so it will move into an "undead" phase of its life whereas MFC will actually die. So Qt will eventually be more popular than MFC. - Jon Harrop
[0] [2009-04-28 23:47:04] taoufik [ACCEPTED]

Future of WPF

WPF's Direct3D architecture lets the graphics card do what it is good in: do graphics. The architecture for sure has a future. I wouldn't be suprised if the next Windows versions would make WPF enabled application GUI's run much faster, without any code change. Windows Vista and upwards already runs in a Direct3D mode, and "draws" Windows Forms GUI's in a backward-compatible way.

In my opinion, whether WPF as a platform (not only the 3D architecture) will make a breakthrough, heavily depends on the availability of good tools to support the development process. Microsoft Expression Blend [1] is still limited, Visual Studio WPF designer is even more limited. Also, I think Microsoft should also invest more in how to get visual designers to use tools which produce WPF UI's.

Comparing Qt/C++ with C# UI (whether WPF or Windows Forms):

  • C# definitely is more productive in UI design. There is a good visual designer for Windows Forms in Visual Studio. Further, for WPF, there is Microsoft Expression Blend for visual designers.
  • C# in UI development has a larger user-base. Therefore, more examples and more community support are available.
  • C# as a language has made a huge improvement in .NET 3.5 to cover areas which were harder to realize (LINQ, Parallel-LINQ, WCF, WF, different ORM products) and are still harder to realize in many other languages.

(93) I'd like to add to your list: Qt has better documentation. WPF does have documentation but it's not well organised and the documentation text itself is harder to understand. Qt documentation has a short explanation on the most used features of an API and then a full reference. MSDN only gives you a complete explanation of everything and this makes it hard to use. - Jules
(5) Second on the Qt documentation! - Dr. Watson
(149) Your response is horrible because your response is entirely one sided and has absolutely no mention of the opposing side. When you are promoting one item as being "better" than another you MUST show HOW the one item is better than the other. - Trevor Boyd Smith
(38) When someone asks "why should I pick A and not B?" and the response is "item A has x,y,z and therefore is better than B" is not a valid comparison. Saying "item A has x,y,z" answers an entirely different question "what features does A have?" and doesn't help anyone understand which is better. - Trevor Boyd Smith
(3) Please note as of 08SEP2009: the accepted answer here has +7. Where as the answer by Alan has +19. - Trevor Boyd Smith
so you're effectively saying that QT is the one to go for - the QTCreator app is great and well supported. - gbjbaanb
(3) So let me get this straight. The argument of the downvoters is "wahhhhh, WPF is too haaard! I don't read good!!!" - Pierreten
(2) @trevor you got me, I do favour C# GUI over QT. That's why I gave my opinion in the first place. I hope nothing is wrong with that. Further, if you really did read my posting, you could have seen that I used the words 'better', 'larger' and 'harder'... all these words imply a comparison between the two different products. - taoufik
@Pierreten, the argument is the one told by Trevor Boyd Smith. - CMircea
(24) I suspect WPF user-base is smaller than QT's - EFraim
@EFraim: correct. However, when you're programming a WPF application, you're working 75% with .NET as a platform (ex WPF technology). The platform itself has more users that "NON-UI-QT plus CPP plus CustomLibraries" as platform. - taoufik
(1) Simply because C# and WPF are not cross platform... - Christophe Eblé
@SleepyCod True all the way. I just wonder how many people really want to run their business application outside of Windows. In addition, QT is just the UI. Other parts of your application might require libraries which are not that portable. - taoufik
(5) @taoufik, QT is much more than UI but a real cross platform application framework allowing you to manipulate data structures much more easily than native C++, doing network programming, animation and so on... - Christophe Eblé
(24) GPU-accelerated or not, most WPF apps are sluggish as hell. I think it's a bit misleading to simply say "WPF is hardware-accelerated, therefore it is awesome" when the #1 advantage to hardware acceleration just doesn't usually show. - jalf
(1) @Trevor as of 2010-09-30 the accepted answer has +9 and the answer by Alan has +53, by user14116 has +25, by Kensai has + 18, mine has + 14, and so on. A lot of people agreed and even more agree today that Qt would have been a better choice. - CMircea
(1) @jalf works on my machine. Also, Visual Studio 2010. - Will
(3) @Will: VS2010 isn't exactly what I'd call speedy. Also note I said "most" and "usually". And, of course, that performance was a huge problem during the development of VS2010, as documented on various MSDN blogs. The current performance level (which really isn't impressive) wasn't easily achieved, and most WPF apps I've seen are far, far worse. My point was just that one API being GPU-accelerated isn't a good thing, unless that API also results in faster apps. In my experience, WPF at best achieves parity with apps using non-GPU-accelerated apis. - jalf
@jalf vs2010 runs as fast if not faster than 2008 on all my dev boxes (core 2 duo, core 4 duo and i7--damn, my neckbeard is strong). Yep, MS definitely did put off optimization towards the end of 2010 (that's why it was delayed, IIRC). Of course, that's usually considered a good thing. The main issue I have with your statement is that you compare your perception of different applications of unknown quality written by different people. That's a lot of who knows all wrapped up in there. (cont) - Will
(3) I've got a stupid little POS WPF app that has pretty damned complex UI designed for a touchscreen that runs on a relatively ancient vanilla Dell p4 with a gig of memory and XP. And it manages to keep up the pace in a busy bar down where all the students drink their scholarship money away. In my experience, not only does WPF achieve parity BUT ALSO it is TREMENDOUSLY easier to code and maintain. Don't hate, appreciate. - Will
(5) @Will: So your problem with my statement is that I try to keep it relevant to the question? My statement was simply "screw hardware acceleration, what matters is perceived performance". I never said anything about whether it was easy to code and maintain, I never said "WPF is evil, and must be burned at the stake". I never said that I hated it, or that I don't appreciate it. But someone above suggested that WPF is better because it is hardware-accelerated, and I wanted to shoot that down because it is utterly irrelevant if it doesn't make the apps actually feel faster. - jalf
(1) I don't know if I can express it much clearer. You come across like a rabid fanboy though, which isn't making it eaiser. Rather than blindly defending WPF against (non-existent) criticism, read what I wrote. I never said WPF sucked. Just that the fact that it is hardware accelerated doesn't seem to actually make it noticeably faster than other technologies, and so that isn't in itself much of an advantage. - jalf
(1) Also, MS did not put off optimization until the end. It was an ongoing priority, they just failed at it until near the end, and it's hardly a good thing when it forces the product to be delayed. Again, they documented pretty thoroughly on blogs and elsewhere that they focused on performance from day 1, and they thought they were on track until the first beta was released. Turns out speeding up their WPF code was harder than they anticipated. - jalf
(1) @jalf Not a rabid fanboi, just tired of fud. Responding to your comparison of dissimilar things resulting in your opinion that "WPF at best achieves parity" and that the current performance level of 2010 isn't "impressive." I base my statements on when performance was concentrated on comes from scottgu; I leave it to anyone who gives a damn about this to read it for themselves. As I stated, they pushed to concentrate on performance improvements; "did put off" "until the end" was too strong. - Will
@jalf I think we do agree that hardware acceleration doesn't mean much for your standard desktop app. Its only when you start doing more impressive things like using shaders or animation or HD video that video acceleration makes a difference. - Will
(2) Hang me for resurrecting this thread, but Microsoft actually invented fud :D as of performance, WPF performs better than WinForms, but it feels like there's something slowing it down, and when pressing hard, it shows. Occasional lags add up. As of Qt, Qt uses native controls so it depends on the OS. I'm not comparing their perf, they're based on different technologies (and IE9 still lags in UX behind Chrome despite hw acceleration), I just want to mention the fact (an offtopic one) that Windows XP with Office 2003 on a Pentium 4 was way faster than Windows 7 with Office 2010 on i5. - Luka Ramishvili
(2) Qt is cross-platform and this is something that will count in the near future. MS time is over, better start learning Linux. - doc
"WPF is better because it is hardware-accelerated, and I wanted to shoot that down because it is utterly irrelevant if it doesn't make the apps actually feel faster". WPF uses hardware acceleration to improve fidelity, not just performance. So that point is obviously not irrelevant. - Jon Harrop
[0] [2010-04-06 11:30:30] brasi

I believe that the only reason you should consider is the number of components available for your framework, if you do not want to cross platform (in that case you have to choose Qt). Windows Forms and WPF have several third party components, eventually for everything you need. Qt framework is probably the best in terms of design and surely can give you better visual experience, but it still lacks professional addons (try to realize a component to access your USB device for example, or try to realize professional charts, such as the Dundas [1] ones, etc.).