You should look up wxWidgits. Its alot simpler to use than Win32 (In my opinion) and achieves similar results. Also, if you use Code::Blocks, there is a wxSmith plugin, allowing you to drag and drop elements onto a form then have it write the bare bones of a code for you.
The only problem with Owain's suggestion is that you need to know a crapload of other things in order to build wxWidgits and maintain it, along with C::B, as it is in development stage all the time.
It's also the GUI toolkit Stroustrup uses in his C++ tutorial book (Programming -- Principles and Practice Using C++). The version of FLTK he uses can be obtained from his site, as well as the FLTK site. http://www.stroustrup.com/Programming/
I would never recommend using the OS API directly if it can be avoided. This is certainly true when dealing with the GUI. Every major OS and some mobile devices are, for the most part, abstracted behind most of the major GUI libraries. There is no reason not to take advantage of that, especially when they provide facilities over the OS that the OS may not provide such as sizers (or whatever they use now adays, I hate making GUI's).
If you find a single platform GUI library, then use that. Using a multi platform GUI library is something I wouldn't recommend. That's just me. My logic is that you can optimize code for every platform. No sense in trusting one library to do it all.
This isn't true *at all*. The theory is that every platform provides similar functionality but gives a different interface to using that functionality. Using a library, you can abstract that functionality under a truly universal interface abstracted outside of the OS.
Take this for instance: Standard C++ runs on ANY architecture that provides a C++ compiler. Under your view, we should all be using assembly since a C++ compiler cannot perfectly optimize for each architecture (despite often doing a better job than the people who actually write in assembly).
You are taking my logic to the extreme. There are plenty of forums where people get bashed for thinking that way. We know the compiler cannot optimize code for every architecture perfectly, but that is not the issue. The issue is the code in the libraries. If you have an awesome library that comments out every line of code you don't need, then yeah, I want your library. But I would have to assume that most libraries have a ton of extra code that isn't needed. Perhaps I am wrong.
Also, I didn't mean optimize the code only for platform. That was my mistake I didn't fix. If you use the win api, you can use what you need from it and leave the rest alone. Most multi platform gui libraries come with a ton of extra functions that are useful, but won't be used. That's a lot of extra baggage to be carrying around in MY opinion. I have tried all the libraries mentioned in this thread. They each require different things to work, and they have so many extra features that I do not need. I'd rather just get comfy with a specific architectures given api, then make my own library with only the stuff I need.
Makes good sense to me. If you think it is unreasonable, then say that. If I am wrong in thinking that these libraries carry to much weigh, then say that too. But also give me some more facts. I could use them, and I'm sure the op can too.
It seems like you're assuming that because a library is cross-platform, it is infinitely bulkier and inefficient than native API's. Performance on Qt is excellent, and the signal-slot mechanism is very efficient, certainly faster than callbacks. Qt does use up a large amount of memory, however.
So sure Native API's are going to be more efficient, but I've found Win32 to be incredibly frustrating to use, and Qt is lovely to work with. You'll be saving development time (not to mention the amount of time that will be saved when you suddenly realize "Hey, I do want my program to run on a platform that isn't Windows" and start over with a cross-platform framework), and when you're program is running on multiple platforms it's worth the *slight* performance drop.
No. I don't assume anything. I know you have the option of choosing what you want, but options only go so far. I will agree with what you have said though Easier, but more memory, longer load times for some libraries. It really just matters on what the programmer wants to use.
Surely using Win32 is going to be incredibly frustrating. It's windows. Once you get a library going, it's most certainly more fun to use. And yeah, you'll save development time, but at what cost? That's for you to decide. But for someone who is developing software for an actual product will probably make their own GUI, not use a dynamic library. I don't think I have to go out of my way to give example of why.
Id rather just make a new underlying library for each machine my software is going to run on. Then I can pick and choose what I want and know what I'm going to get.
So, I think the answer comes down to preference. But, in my opinion, the op won't know which one he prefers unless he tries. I've tried all of these, so you go try now and decide which one you like most.
If the GUI needed to be super fast, I might would agree. However, most libraries are based not around efficiency but around usability. A GUI doesn't need to be super fast or efficient.
Making a decent GUI is f*$king hard. The least you'd want to worry about is platform specific problems and the crappy API oriented with each OS.
I wouldn't say it generally matters most, open ended.
I would say it generally matters most to people who choose to make cross platform software in one go, instead of different versions for different platforms.
I would also say that most professional software wouldn't want to be lagging behind because of the library they used. But. I really couldn't say what companies do, and if I did, I wouldn't be here wasting time chatting about.