As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Pros. and cons? how long do you use it? What about jambi?
I have been using Qt for several years now for commercial development and have been very happy with it.
One of the nice things with Qt is that it provides a large set of libraries as well as the GUI stuff (eg XML parsing, threads, networking), all in a consistent style and all multi-platform. This means we rarely need to use other libraries, though we do use boost for some things.
Another very important factor for us was internationalization. In a previous, MFC based application we had to maintain 2 localized versions, for the two languages we support. In our Qt based app we just have the one version.
The Qt translation system, using linguist is easy to use and makes supporting multiple languages easy (of course you still have to translate the strings which is a lot of work!)
The GUI layout system where the widgets resize themselves according to a layout makes everything much easier. In different languages the length of the strings are different. With fixed size widgets (like MFC) each dialog needs to be adjusted for each language, otherwise parts of labels get cut off. With Qt they resize themselves. Of course, there are cases when it does not work exactly right but it still makes everything much easier.
QString does everything in Unicode and handles the conversions from different codecs very easily.
One thing that has been very valuable is the access to the source, although e this is certainly not unique to Qt. On several occasions the ability to check the Qt source has explained some strange behaviour or given a clue how to achieve something.
We have found a few bugs in Qt, some of which have been fixed after reporting to Trolltech. In other cases they have suggested a work around. These have all been fairly obscure and not had a major impact on our development.
One of the main downsides to Qt would be the lack of 3rd party libraries for use in commercial applications. However, Qt is fairly complete so for us it has not been a big problem, though that will depend on which type of application you are developing.
I have not used Jambi either.
I've used Qt on a couple of projects I did in c++ on several platforms over a period of seven years. I think it works pretty well and definitely was quicker for me to develop a decent GUI app on the Mac than plodding through a language I didn't know (Objective-C) at the time.
I think the signal/slot mechanism is a bit funky but isn't horrible. Once you're use it for a bit, it's not a show stopper. The connection stuff is easy to bungle up (or at least it was) and it's always good to check the return on those because your app will go merrily on its way and not tell you that it didn't work.
I've never used jambi.
Here are some of my Pros and Cons with Qt:
Pros:
Cross-platform
I know this one is always used, but after going back and forth between Windows and Linux with Qt, it's amazing how little I have to do to get up and running. I think this is helped by the fact I only use Vim with Qt Designer.
QMake
This is one of my favorite aspects of Qt. After doing work in wxWidgets, FLTK, etc., I get so tired of messing around with different build systems and I don't want to manually create my makefiles. I currently use CMake on anything other than Qt right now, but I think I'm slowly moving even Qt over to CMake. However it's just so easy to get going with QMake.
QTestLib
I looked at a couple other C++ unit testing frameworks and when I created my tests using QTestLib, it felt very similar to NUnit(C#) and within minutes I had several passing tests. I also noticed that it would be very easy to create my own continuous integration environment.
Closest to Java and .Net in productivity
The biggest thing I hear/read people say about C++ is, "I can be more productive with Java or .Net". From personal experience I can get a prototype of an application running in Qt using Vim and Qt Designer, before Eclipse or Visual Studio even load. I also get a very similar set of libraries in Qt that I have in .Net or Java and if it's not there I can leverage the existing C++ code out there.
Cons:
Price
This is the biggest factor I can think of right now. However, the cost is worth every cent, um if I knew how many cents I had to save up without making a call to a sales rep. I purchased a license back in the day when they had their small business discount and it was worth it then, I would've paid three times as much and I think that's the current price.
Develop anywhere with commercial license
I would love to be able to develop on any platform, but build and sell for another platform. For example, develop on Linux, then build and deploy on Windows if you just have the Windows commercial license. From what I know, you can only develop and build a commercial application on the platform you have a license for.
Vendor lock-in
Well sort of, this is more of a personal con. I don't like being tied to a specific vendor because I get side tracked by the company direction and product direction. TrollTech was purchased by Nokia, is this good or bad I don't know, but a company that size can do evil things.
I think I'm done for now :). Oh, I haven't used Jambi but I'm really interested in doing a couple prototype projects to find out how easy it is to use a plugin developed in C++ with Jambi. Especially using Jambi as a web interface with C++ plugins.
To be honest I haven't read much on it, so it may be impossible or very easy.
I used Qt in a previous job. I'd only had the absolute briefest of contact with Qt several years prior to that, so I was pretty much a Qt newb.
When I started I was told to choose my language and environment, but cross-platform support was desirable. I tried Qt and Java, and even gave C# a go just for the heck of it. I gave myself two days to evaluate each option.
Maybe I was slightly biased with my history as a C++ developer, but after spending time on each option Qt was the only one that showed any hints at being useful without a long learning curve.
The documentation provided with Qt and the example applications made it very easy for an experienced developer but Qt beginner to get up and running very quickly. I had UI prototype/mockups of the end application done by the end of my trial period. With Java/Eclipse, Java/SunStudio and C#/VS.net I had trouble getting anything nontrivial happening in that time.
Signals/slots took some getting used to, but it wasn't too bad, and I wrote some simple wrappers to assert when connections failed to stop silly typos from stopping the app. from working.
The other thing I liked is that Qt had almost everything I needed. You name it - storage, networking, GUI, threading, containers - Qt has a class to deal with it. Which IMHO is important because mixing libraries can sometimes cause problems.
Having the source code to Qt was a big plus, one for just plain interest's sake, but also it allowed me to compile Qt using the compiler and settings of my choosing, including a debug version for use during development.
I also found Trolltech's support to be fairly good. I raised a couple of bugs on Qt, one of which was fixed and released whilst I was still working on the project (only a 6 month job).
The only negative I can recall was the difficulty in debugging Qt objects (using VS) - there is a Qt plugin for VS that can examine Qt objects but I was using the free version of VS and plugins don't work for it. But that wasn't Qt's fault.
I haven't used jambi so can't comment.
On C++ your only other alternatives are MFC and wxWidgets.
QT / wxWidgets is largely a personal preference. I do think QT is a clean design with good documentation.
QT costs about one month of developer salary if you aren't using it for GPL.
I have been using Qt for over two years now.
Things I like on Qt are:
Easy GUI programming (compared to
MFC), Qt Designer
Nice container classes
Nice graphics scene framework
Excellent documentation with useful examples
Translation support
Good technical support
I can highly recommend the Qt Developer Days. If you have a chance to take part, then do it! Lots of nice and very interesting talks there.
Qt is a very nice library, but it has an expensive per-seat developer license, so it's not always useful for all projects.
Don't use it, however...
Pro:
QT has an optional 3 phase layout, where as WX only allows for 2 currently (I believe they plan to do 3 phase, just have not worked it in yet).
One of the bigger problems with using layouts is static text and wrapping. WX asks how big is your min width/height and portions out the screen, QT has option to say how wide do you want, how high do you need to be if your X wide. This allows you to express the flow of a page much better.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
https://stackoverflow.com/questions/149698/what-is-a-good-mfc-starting-book
A lot of the upvoted comments claim there are much better alternatives. I'd like to know what they might be.
My main requirement is that the UI use the native widgets so that our automation software can work. Owner drawn windows are much harder to drive.
I'm not particularly liking the design of MFC so an alternative would be good. Only one I've found is WX, which is the one we've already tried and are considering abandoning. We need something that doesn't force us to fight with a bunch of cross-platform wrapping we don't care about. We're writing a Windows application and marketing doesn't give one single crap about targeting Mac or Linux (yeah, it makes my butt hurt too).
I've looked at the .NET option a little bit. Problem is I don't know much about it but from what I can tell we'd have to use C# to get a lot of the options readily available with MFC. The C++/CLI toolkit doesn't seem to have docking windows on first glance for instance. In fact, a straight up WinFroms option doesn't seem to either. It looks like we'd have to make a WPF project and that doesn't appear to be at all what we really want (and we'd have a huge bunch of crap to learn besides just another toolkit). Moving out of C++ would also require a lot of wrapping and I don't particularly like the results I've seen from automated wrappers.
The other issue I have with the .NET option is that we've got a pretty drawing intense application (in addition to requiring a lot of forms). I know that you can get similar results with JIT languages like .NET but I also know you've got to be a lot more careful to do so. It's an issue I'd like to avoid worrying about at this time.
The other, and probably most important issue with .NET (at least switching languages) is that we've got a huge supply of interface logic that though should be API agnostic, is very much written in C++.
So what are the other options? Do these people really have points or are they just yelling against anything that isn't their favorite language or toolkit?
NOTE:
What is the issue here?? I said specifically that porting to other platforms is NOT even remotely a consideration and that I HAVE TO HAVE something that uses the native widget set so we don't have to completely change everything that testing uses to automate the product!!!! Did anyone actually read my question?
Qt is the only real answer for a C++ based gui toolkit at the moment (at least for full desktop apps). Even for purely windows apps it's worth it - it also has excellent integration with visual studio (get the vs-addin) and is very well documented
wx has some nice points, one being it's very similar to MFC in use, but with Qt going LGPL wx's real advantage has been lost.
Edit
Qt widgets aren't native HOWEVER they do use the native styling APIs so that they are indistinguishable from native widgets - if you use the default styles.
Windows forms will work just fine with C++/CLI. Windows forms also happens to be a wrapper around WIN32 handles.
There's no difference in the capabilities of C#/Windows Forms compared to C++/Windows Forms. (They just compile differently) Just like you can do the same things with C# and VB.NET...
If you're looking for docking windows, there are a number of third party libraries that do this. (Some are open source, some you can buy.) Because of the CLR, you can directly include assemblies written in a different language.
MFC wasn't bad in its day but it is getting a bit old. A good example would be the collections which have been replaced wit the much better STL collections. However you were asking about GUI stuff. There's the WTL (Windows Template Library) which I believe has now been open sourced. Much lighter footprint than MFC but it is designed to work the same way - eg. Most of the classes have the same names and method names.
On the downside I've found documentation relative scant and it doesn't seem to work well with the Visual Studio Wizards. This could be my problem though - getting it work with the VS wizards would be quite important IMHO.
I'm in roughly the same position: large app, native code, using MFC for the front-end. I don't see any really compelling alternatives, or reasons to switch to anything else.
That being said, let me offer an opinion. If I were doing a new project, which needed to preserve/inherit a lot of native code, I'd consider trying to do a WPF front-end with a largely native (C++/CLI) main application. This was done with Visual Studio 2010, and it's mostly performant, so it's at least possible. WPF has some UI benefits, and it might be easier to work on and test (from an automation perspective), since it is CLR code. I'm not sure it would be worth the investment and learning curve, but it's the alternative I would consider for a modern pure-Windows application with lots of native code.
Hope that helps.
To offer something I didn't see mentioned in the other answers:
From the sound of it, your only reason for needing native controls is that automation software. And the only reason for needing that automation software to work is for testing. I would assume some series of automated tests are being used to ensure the software works as intended.
If that's the case, then here is something to consider: There is a reasonably popular design pattern in the C#/WPF realm called Model-View-ViewModel. Without getting into excessive detail here, the basic idea is that you can separate the actual GUI controls (the View) from the code that handles how those controls interact with the rest of the business logic in the application. That code is the so-called ViewModel. Among other things, this lends itself to designs where that ViewModel (and all the rest logic of the application) can be tested through typical unit-testing methods without actually needing GUI controls to be present.
So whatever testing the automation software is used for could potentially be replaced by straight unit-testing code.
However, my own experience in this realm is not nearly as extensive as I would like. So if you consider this at all, I strongly suggest further research. As a start, googling terms like "Model-View-ViewModel" and "MVVM" should eventually yield some more detailed discussions about that part.
I've seen Qt used fairly extensively. I personally have not used Qt, but I see a lot of questions about it, far more than wXwidgets or MFC. I'd start with that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
While I have played with parts of Qt in the past I am thinking of putting some real effort into learning it but also wondering what the potential monetary payback might be down the road. So I have some general questions about Qt's future.
What is Qt's place in the job market? Are there many, or do you sense a growing number of installations using it? What are its main competitors?
What kind of enterprise niches does Qt satisfy? Are more corporate applications trying to be cross-platform these days or do most of those efforts go the Java, etc., route?
Since being bought by Nokia I assume Qt has a viable future on mobile devices. Has this in fact been working out? Is Qt pretty much limited to Nokia offerings or does it have a place on Android devices, etc.?
Please feel free to comment on any aspect of Qt's future that I may have missed.
Don't have a real answer for you, but I recently saw this diagram for job trends with various C++ libraries.
They have been around since 1995, and recently some feared that Nokia would buy them to stifle the competition in favour of Symbian. Now that seems definitely out of the way by the way Qt will soon support Symbian and Maemo 5. Seeing the effort they spend in R&D and what their framework already provides on so many platforms, I wouldn't worry about their future.
As an open-source platform, I would venture Android devices are more of a competitor, rather than a possible platform, but it's just a wild guess ;-) There are some fierce debates out there on the subject.
Another real competitor would be .NET, both offer more than just IDE building tools and deal with workstations and the embedded world.
Clifford's advice about not sticking with only one framework is very wise IMHO. Another argument to start with Qt beside the advantage of covering more platforms is that it uses the C++ language, which is more demanding than C#. Starting with that will give you good programming habits, and it will be much easier to investigate something else later, be that a C# or a Java-based framework: you'll have a better idea of what lies behind the scenes of memory management (if that is not already the case, that is), and your code will be potentially more efficient.
I started using Qt in 2007. I liked it a lot, but the price meant that I couldn't use it as much as I would have wanted to.
The Nokia acquisition has been a good thing so far: (ex)Trolltech have completely opened up their development process. You have access to their VCS and bug tracker, you can contribute code, test development snapshots, open and track issues and so on. They value input from the community.
The framework is high quality and very popular in the open source world (KDE comes to mind). LGPL licensing has resulted in a bigger adoption with commercial software developers. This year's DevDays has seen a record attendance.
What is Qt's place in the job market?
I'm not based in the US so I don't know what the situation is over there. Most C++ jobs are MFC in my area. I know of a few places that use Qt.
Are there many, or do you sense a growing number of installations using it?
I've definitely seen more interest in newsgroups/forums/online communities.
What are its main competitors?
.NET on Windows, Cocoa on Mac and GTK+ on Linux. When it comes to C++ only wxWidgets, MFC or WTL could be considered as alternatives, although I would argue that Qt is in a different league from them.
Is Qt pretty much limited to Nokia offerings or does it have a place on Android devices, etc.?
Qt is also available on WinMo/CE and Linux devices. Symbian is not Nokia-only any more.
I don't think that we'll see an official Android or iPhone port. Right now they're working full steam on S60 and Maemo support.
Qt is one amongst a number for GUI frameworks and libraries, such as wxWidgets, Windows Forms, MFC, GTK+, VCL and many others. I suggest that the choice of framework is seldom a critical business decision, the choice is most often determined by such things as platform, functionality required, existing developer experience, and development tool support.
A general working knowledge of GUI frameworks is probably far more useful since it would make your skills more portable. Specialising in a single technology seldom pays in this business, flexibility and an ability to acquire new and relevant skills quickly is.
However Qt is the basis of the KDE environment, so for any Linux development targeting KDE, Qt would be a useful skill.
I know for a fact that this company's products are Qt based to provide cross-platform portability.
I've been doing contract work using the Qt framework for about two years now, for entertainment software. Here's what I have found:
It's a great toolset for developing
cross-platform applications. Easy,
fast, powerful, advanced. I never
feel constrained using it. Since it's developed in C++ you can easily embed any
number of C and C++ libraries out
there and quickly delve into the native system
APIs when you have to. If it has a niche I would say it's performance critical GUI applications, dealing with 2D/3D graphics...etc. I personally have not seen an enterprise-level company which uses Qt.
I live in the South-Eastern US
(Atlanta) - I rarely see any job
offers around here, mostly .NET or Java. The job offers I
see tend to be on the West Coast, or
overseas. However, I do see more
than I used to, probably due to Nokia's involvement.
I do feel it is growing in
popularity instead of shrinking. I
see things like QtCreator and the
like as good indications of this.
I'm doing embedded development and see Qt increasing market share with innovative ideas. Stopping QtExtended worried me for some time, but now I'm convinced QT in embedded is growing rapidly.
Not only in mobile/smart phones, but automotive as well.
Wanting your App cross-platform for Symbian AND Maemo AND WinCE AND Linux (AND all Desktop) platforms, I don't see a competing Toolkit.
Yet I have no seen a company hiring that skill, but everythin under LGPL and developments like Qt Mobility are quite new.
Qt is not available on Android, link: http://sourceforge.net/p/necessitas/home/necessitas/
And it will be made available to more platforms with project Lighthouse.
STL/Boost cover all the low level stuff.
But what about the higher level concepts?
Windows: We have multiple windowing libs
KDE(Qt)
Gnome
Motif(C but written in OO style)
MS Windows
etc
But is anybody working on a unified standard for windowing?
Something that wrapped all the above would be acceptable. (even if it only accessed the common stuff it would be a starting point).
Networking:
There are a couple out there (including the Boost low level stuff).
But is there anybody working on a Service based network layer?
All the other stuff that Java/C# have in their standard libraries.
The stuff that makes it simpler for a beginner to jump in and say Wow done and it works everywhere (nearly).
Anyway. Here hoping there are some cool projects out there.
Edit
Maybe there is not one.
But if there are a couple that could be bundled together as a starting point (and potentially modified over time (where is that deprecated keyword)) into a nice consolidated whole.
Note: Windows is just a small part of what I am looking for. The Java/C# languages consolidate a lot more under the hood than just the GUI. What would be a good set of libraries to get all the functionality in one place.
There are too big differences between platforms to get a definitive C++ standard for GUI programming. I think Qt is about as close as you will get in the forseeable future. wxWidgets is another popular choise, but as I understand it, they are using less modern c++ features.
As for networking, I think you are being kind of vague. If you mean web services over HTTP, I would have a look at Pion.
Well it is almost 2010 and C++ almost has threads.
I'll probably get slammed for this but C++ moves too slow - to its own detriment and its user base. I readily acknowledge the difficulty of the technical and political issues involved but that's still the dirty reality of it. The language can't build in higher level concepts when it takes 5-10 years to agree on and implement the building blocks.
The reasons for this have endlessly debated but the sad truth is that C++ has relegated itself to a niche language. I like C++ but I look at the progress C#, Java, and even Python and Ruby have made over the last 5 years and I increasingly question whether C++ is worth the effort.
The Poco C++ project aims to deliver all that you ask, except for Windowing:
The POCO C++ Libraries aim to be for
network-centric, cross-platform C++
software development what Apple's
Cocoa is for Mac development, or Ruby
on Rails is for Web development — a
powerful, yet easy to use platform to
build your applications upon.
Qt might be the only framework complete enough to be what you suggest.
I guess there's some kind of keyword lookup driving the advertising here because I'm seeing a REALbasic ad, which is what I generally use for cross-platform GUI's nowadays.
I have spent a lot of time over the last 15 years working in C++ GUI's including retailing my own portability layer for CodeWarrior PowerPlant and working on the two Macintosh-based GUI code generators, including adding Windows generation to AppMaker. I've worked with wxWidgets, mainly wxPython. So, my opinion on difficulties in cross-platform GUI is fairly well-qualified :-)
Cross-platform GUI frameworks are hard to the point of nearly impossible without significant compromise - the issues come down to subtle matters of behavior which generally bother users at a level where some of them can't quantify but know that the application doesn't feel right. This is a lot harder to fix than just rendering native controls.
I started using REALbasic because their framework does a better job of getting the feel right than anything else I'd tried (I didn't get into Qt because of the expensive commercial license).
The reason it has taken so long for things to evolve is nothing to do with the C++ world moving slowly, it's just an intractable problem. The very best cross-platform Java apps do some stuff conditionally for OS/X and it is still screamingly obvious to an experienced user that they are not a native Mac app, although some are very usable and come pretty close to looking native - Oxygen XML editor and DeltaWalker are two of my favourites.
I don't think it is achievable to make a really comprehensive portable GUI library. Operating systems are just too different. Can you imagine a GUI library that would cover everything from iPhone to Windows 7 and wouldn't feel wierd on any of them?
A Boost gui library comes up occasionally.
The general opinion seems to be that the problems is too wide (are you targeting cellphones, FPS games or CAD workstations) and that it is too much work - Qt/wxWidgets has taken 10years.
see http://lists.boost.org/Archives/boost/2005/09/94453.php for a discussion.
It would have been nice because GUI usually means cross platform and threads, so all the GUI toolkits have invented their own cross platform,filesystem and thread classes. On the other hand if a standard GUI had been introduced in C++ it would probably look like TK !
What's so great about standardization ? Sure, if novice coders want to download one SDK to build portable apps, let them download Qt (or something similar) and forever remain within it's fine walled environment. But it'd be a tragedy if the C++ world revolved around that one library and boost and POCO and wxWidgets and clutter and blitz++ and eigen and and 101 other wonderful things (yes, gtkmm and ACE even) were stifled at birth because the gatekeepers of The Standard Library didn't see fit to admit them.
Diversity is good I think (although when dealing with it, it helps to have a good package manager; I've spent hours setting up build dependencies on Windows which just needed a few seconds of apt-getting on Debian).
ACE is great for concurrent communication and networking.
For cross platform windowing, there's wxWidgets. (formerly wxWindows).
Only everybody and his brother, but hardly any of them actually get anywhere.
I'm looking to be able to build GUI applications quickly and painlessly as possible. I'm competent (though not expert, and have no formal training) in C++, but have never used a GUI building toolkit or framework or anything. I am not a professional programmer and am totally inexperienced and ignorant when it comes to building GUI apps. Have spent hours researching trying to figure out what to do; only getting more confused and discouraged though.
Qt and wxWidgets seem like the most popular options for cross-platform apps, though cross-platform isn't necessarily all that important to me; Windows-only is fine if that means the fastest learning curve.
Qt seems cool and the Qt Creator is sweet looking with lots of good demos, except it has its own classes for everything, and I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally. I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
I was thinking Visual Studio would have the smallest learning curve, but when I open a test GUI app, I see a bunch of foreign looking stuff like carats (^) all over the place - I found online that these mean "handles", which I have trouble even understanding the definition or purpose of ("sort of like pointers but not really" is basically how I've read people define them).
I know pretty much nothing about wxWidgets, or how it compares with Qt.
So every option has a big learning curve - and ideally I'd like to know which one minimizes the time you have to spend learning the toolkit/framework itself. Since I'm likely never going to be making money from the programs I create, the time I spend learning a specific toolkit would be pretty costly. I just want to be able to make a functional program using the C++ knowledge I have, but in GUI form. At the moment it seems if I want to make a GUI app, I'd have to spend way more time learning the GUI framework I'd use than writing the functional part of the app itself.
Any input from people wiser and more experienced than me would be appreciated :)
First and foremost, start simple. There's a lot to the subject. If you are finding it hard, don't try and take it in all at once.
Most of the good GUI packages have tutorials. The best advice I can give is that you try each of them, or at least a couple of them. They are the best short introduction you can have to the library you choose and if they are any good they narrow down what you need to absorb at first. That will give you some basis for comparison, because they are each trying to do very similar things (and you will see some of them before you are done), but they have different feels. You will likely find you have a preference for one and that's the one to get serious with. It will also give you a sense of what's hard about GUI programming as separate from the particulars of one package, which, if you have only used one, you won't have seen. Personally I find this sort of knowledge very helpful, because it makes me less intimidated by particulars.
Here's a list of tutorials in one place, though you have likely seen them already:
Qt's tutorial
WxWidgets' tutorial
Gtkmm book. Not quite a tutorial, though there are lots of examples.
.NET tutorials, either for WinForms or for WPF.
Second, it sounds to me that you need to get some in depth understanding of the concepts of GUI programming, not just a particular library. Here there is no substitute for a book. I don't know all of them by a long shot, but the best of the bunch will not just teach you the details of a toolkit, they will teach you general concepts and how to use them. Here are some lists to start with though (and once you have titles, Amazon and Stack Overflow will help to pick one):
List of Qt books
WxWidgets book (PDF version)
There are tons of WPF and WinForms books. I can't make a good recommendation here unfortunately.
Third, take advantage of the design tools (Qt Creator, VS's form building and so on). Don't start by trying to read through all the code they generate: get your own small programs running first. Otherwise it's too hard to know what matters for a basic program and what doesn't. The details get lost. Once you've got the basics down though, Do use them as references to learn how to do specific effects. If you can get something to work in the design tools, then you can look at particular code they generate to be able to try on your own hand-written programs. They are very useful for intermediate learning.
I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally.
I second the comment of GRB here: Don't worry about this. You are going to need to learn a lot specific to the toolkit no matter which toolkit you use. But you will also learn a lot that's general to GUI programming with any of the decent toolkits, because they are going to have to cover a lot of the same ground. Layouts, events, interaction between widgets/controls, understanding timers -- these will come up in any GUI toolkit you use.
However do be aware that any serious GUI package is an investment of time. You will have a much easier time learning a second package if you decide to pick one up, but every large library has its personality and much of your time will be spent learning its quirks. That is, I think, a given in dealing with any complex subject.
I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
You do not need most of the non-GUI classes of Qt to use Qt's GUI properly. There are a handful of exceptions (like QVariant) which you'll need just because the GUI classes use them. I found you can learn those on a case-by-case basis.
Which is the easiest to learn is really going to depend on how you personally learn.
Personally, I've found Qt to be the easiest to learn so far. The GUI classes are rather nice to use, but I've found the non-GUI classes to be excellent, making it easy to avoid a lot of common issues you'd normally get with a more basic API. The documentation is excellent, IMO, as are the books, the examples, etc. It's also being very actively developed, with a few new technologies coming in the near future (like DeclarativeUI).
I've found Visual Studio/Windows API/.Net to be a good bit more complicated to learn. The API documentation on MSDN is rather complicated and not really organized in a manner that I find intuitive.
I've tried learning WxWidgets a few times, but I've never liked the API documentation.
All this is just my personal experience, YMMV of course. I'd say just dabble in all of them and see which one takes you the furthest, it won't hurt to try multiple.
As a person who learned C++ through Qt, I can only say that they work very well together. C++ purists (like I have become) will find lots of things in Qt not to their liking (the moc preprocessor, e.g., and the continued absence of exceptions for error reporting), but looking back, Qt provided a very gentle introduction to C++ for me.
And if you're like me, you throw in a handful of boost libs in each Qt project, because we want to write "real" C++, not the softened thing Qt uses :)
I would suggest wxWidgets. To me, it's pretty intuitive and looks nice.
Code::Blocks was built with it, so check that out to see if you like the graphics.
There are also a slew of bindings for wxWidgets, such as wxPython, wxErlang, and others, so if you decide to switch off of C++, you can take wxWidgets with you.
I also use wxWidgets and use it all the time for Windows-only applications (the only downside is that wxWidgets is notorious for large .exe filesizes, which may or may not be a problem for you). I found it very simple to use from the start, especially when combined with a GUI designer (personally I use wxDev-C++).
I've never used Qt, so I can't speak to its simplicity, but I doubt the difficulty is on a vastly different scale than that of wxWidgets. However, what I can say is that no matter what API you use (wxWidgets, Qt, WinAPI, etc) your code will be "locked into" that particular platform, so don't worry if you feel that learning Qt will lock you into the Qt platform (because the same thing will happen with any of those APIs).
If you're working solely on Windows however, you may want to do a few simple programs with WinAPI first. That way you have a basic understanding of the lowest level of Windows GUI programming before you move onto Qt/wxWidgets. That said, if you're really into cross-platform programming, then don't worry about that and go straight into Qt/wxWidgets.
I can't intelligently comment on the learning curve aspect, but a quick survey of StackOverflow questions shows about twice as many Visual C++ questions as Qt questions. Probably means that there is a larger support group in place for Visual C++. Might make learning it a little easier if there are more folks to help out.
No matter what you pick, I am quite sure it won't be easy and painless.
Having said that, I know that in some schools they use FLTK because they consider it relativelly easy to learn. I have never tried it.
In my everyday work I use WTL which is as close to the system as it gets while still providing some level of abstraction over pure Win32. I am not sure if I would consider it easy to learn, though, especially given the lack of documentation.
I recommend codegear C++ builder (previously known as borland C++ builder) from codegear which comes with a 30 trial. The nicest thing about it is that the GUI provides you with components that you drop onto a form in a WYSIWYG fashion and make functional by adding code to handle the events it fires. It comes with a whole bunch of compontents out of the box and you can add 3rd party components to it too, like the awesome ExpressQuantumGrid from devexpress, or write your own. It's very powerfull if you know what you're doing but intuitive enough that a beginner can write a database CRUD application in about 20 lines of very simple code.
Since nobody has mentioned it yet, for the sake of completeness, have a plug for the Fox toolkit. This is the one I used last time I did any C++ UI work of my own volition. There are also binding for this to Ruby and Python (the latter being many years out of date, though).
In general, the choice of a toolkit for self-directed work comes down to personal preferences for
the layout manager style
the event handler registration style
How native the widget set looks/can be made to look
If cross-platforming is not necessary, try .net + msvs or delphi. easy, all-in-one, no pain.
Qt is the best option for you. It's the easiest to learn, the most elegant and powerful and it is completely free.
Visual C++: This is an IDE, but it comes with its own GUI library called MFC. MFC is an old library with many quirks and it is difficult to learn and use. Many C++ programmers use it on Windows because it comes from MS, it's fast and it's free if you buy Visual C++. Since VC++ is an IDE, you can also use wxWidgets and Qt with it, although in your particular case I would recommend Qt Creator instead.
You seem to have experimented with Managed C++. Don't use that, even MS recommends that you only use Managed C++ as glue between C++ and C#.
wxWidgets: This one was a strong contender up to the day when Qt became free for commercial projects. It was always in the shadow of Qt and it is known that the documentation is not very good and the API is not as easy to learn as Qt's. Cross-platform MFC would be a good way to describe it.
C++ Builder: Borland made too many mistakes with C++ Builder and ended up getting out of the dev tools business altogether. It was a good product and I originally learned Windows GUI programming in one of the first versions, but I won't use it any more. There are better options and it is too expensive.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am writing a fairly large and complex data analysis program and I have reached the point where I think it is about time to build a GUI for the program. So my question is:
Which GUI toolkit should I use?
I am completely new to coding and building GUIs and would appreciate any guidance that can be offered. It doesn't have to be the simplest tool kit in the world, I learn rather fast. However, it does need to be able to do the following things (some if not all of these are probably incredibly basic for any given toolkit but I thought that it would be good to throw all this out there just in case).
It has to allow me to draw directly to the screen so that I can put graphs (spectra really), plots and things like them up for the user to see. I need to be able to collect position information on where they clicked on aforementioned spectra. I need to be able to display text and take text input from the user. It needs to be able to generate menus (you know File, Edit, etc). If it were to have some built in widget for generating tables that would be handy (though I can surmount a lack of that if I can draw directly to the screen). It needs to be able to pop up warnings, dialogue boxes, save and open boxes, etc. That is pretty much it, most of these seem pretty basic when I write them out but I don't want to get the GUI partly coded and then realize that I I need to rewrite it with a different toolkit.
It should be noted that I have written this program in C++ and that I don't want to have to write the GUI part in C or something else so the toolkit needs to support C++.
Additionally a cross platform toolkit would be preferable over a single platform toolkit. However if it must be a single platform toolkit then I would prefer it be for Linux.
Finally, I would DRAMATICALLY prefer an open source toolkit to a closed source toolkit.
Beyond that I cannot think of anything to add. Thank you in advance for your time and answers.
Hmmm based on the answers I shall look at both Qt and wxWidgets and see which appeals to me more. I with I could accept multiple answers as accepted but I can't, and since I am looking at two things it would be unfair to only accept one of the answers, perhaps in a week or two then I have looked at the toolkits and figured out which I want to use.
For C++, in my opinion, Qt is the least frustrating and most fully featured toolkit. Its also fully cross platform. Note that Qt will be LGPL licensed some time in March 2009, when version 4.5 becomes available. Currently, its only offered in a GPL and commercial license version.
Qt's GUI designer is good. It has lots of utility functions (scene graph library, translation support, built-in Javascript engine, built-in WebKit library). Via the MOC (a special pre-compiler) it also brings a few run-time binding capabilities and introspection to C++.
For your technical application, you might find that Qwt (http://qwt.sourceforge.net/) provides what you need. It is built upon Qt.
Qt can even be used "headless" if you want its utility support (such as networking, etc) without a GUI.
The other cross platform C++ option is wxWidgets, which is usable but not really comparable to Qt. Its a much lower level toolkit, and isn't as easy to use or fully rounded. Gtkmm is another option, in the spirit of GTK+.
Try WxWidgets. Cross platform (compile on Linux, Mac OS X, and Windows) and widely accepted.
http://www.wxwidgets.org/
Open Source too!
I see nobody commented on GTKmm. It is the C++ incarnation of GTK+, and it is a real pleasure to use. I have also used Qt, but I don't like the messy signal/connect code, the moc_XXX generated files, etc. GTKmm has signals and such, but not that preprocessing step, as well as almost all of the Qt toolkit can offer in the graphics arena.
I'd say it depends on whether or not you want the native Look and Feel of the OSes you're targeting for your application. Qt, like said earlier, is probably the easiest of the cross platform toolkits to use, however it is its own widget set. You don't get a native app look & feel unless you happen to be running on KDE.
I use wxWidgets at work. It can be frustrating at times and in some places not very polished, but it does give the native look and feel for the platforms you're targeting. It actually wraps the native UI controls to give them a common API on all platforms that wxWidgets is ported to.
I had the same question and searched for good GUI toolkits.
At the end I found out, that a GUI toolkit isn't enough - I need a complete platform independent solution providing me the build environment, IDE integration and lower level functions like network sockets and file I/O.
My result? Since nearly 9 years I use Qt (but the first years only for GUI stuff) - now I have highly complex networking apps with load balancing, massive multithreading and image processing.
You can use Qt as commercial user with professional support (like me) or just start your own projects under GPL and with 4.5 with LGPL (which allows commercial use).
The other alternatives like wxWidgets and GTK++ are very good choices for GUI programming.
But if you want a well documented and complete solution, then Qt is your choice.
Best Regards,
3DH
I'd also recommend wxWidgets together with DialogBlocks, which is a really nice visual GUI builder.
I will say that wxWidgets has a few rough edges, but the development community is very active and extremely responsive to bug reports / questions / contributions.
I use wxWidgets(toolkit) + wxFormBuilder(gui-designer) + eclipse(ide).
All tools are cross-platform and free.
Qt. Also you can use KDE which is built on top of Qt.