Qt versus WPF/.NETMy 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?
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.
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 http://qt.nokia.com/doc/4.6/index.html 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.
[1] http://doc.qt.nokia.com/4.7/supported-platforms.htmlTwo 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.
[1] http://en.wikipedia.org/wiki/Visual_BasicThere 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.
[1] http://en.wikipedia.org/wiki/Qt%5F%28toolkit%29#BindingsReading 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!
[1] http://www.qtsoftware.com/products/developer-toolsThere are a few points worth considering before making any decision
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.
[1] http://code.google.com/p/qt4dotnet/Please note i am a WPF Programmer. Therefore i can say you WPF details not QtQuick
However,
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)
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
Declarative UI [1] is Qt answer to WPF. Looks very promising.
[1] http://www.qtsoftware.com/developer/qt-roadmap#declarative-uiAnother 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.
Having worked on Qt for the past few months I can say that-
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.
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.
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.
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.
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.
[1] http://en.wikipedia.org/wiki/Warren_BuffettQt 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.
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.
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.
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.
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.
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: http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx
ACCEPTED]
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.
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.).
[1] http://en.wikipedia.org/wiki/Dundas_Data_Visualization,_Inc.