I wanted to explore and know about the GUI toolkits available to be used with C or C++.
I heard a bit about Qt, GTK, Mingw etc, and there's MFC too.
For the moment I am not quite sure which one to start with. Does a programmer need to know all of them? Which one do you pros use mostly in real life? Is one more important to know than the other?
Could anyone tell me about GUI in C++ in general and the toolkits/libraries available?

depends on the operating system. QT is portable between both *nix and MS-Windows. The others are not portable. I'm not a *nix programmer, so I can only say that on MS-Windows the Visual Studio .NET 2003 (2005 coming out this month) are the best. But again, it is not portable to other operating systems. You might also check Borland products.

I wanted to explore and know about the GUI toolkits available to be used with C or C++.
I heard a bit about Qt, GTK, Mingw etc, and there's MFC too.
For the moment I am not quite sure which one to start with. Does a programmer need to know all of them? Which one do you pros use mostly in real life? Is one more important to know than the other?
Could anyone tell me about GUI in C++ in general and the toolkits/libraries available?

Sure. If you are just starting out with GUI's then stay away from MFC, far, far, far away from MFC. In fact, always stay far away from MFC, there are things out there that surpass it in every imaginable way. My main beef with MFC is its resource editor. It doesn't work half the time and it produces horrible code sprinkled with the most obnoxious comments. Then the whole MFC class library is completely unintuitive, and I swear it was written by monkeys.

Gtk is really good, Gtkmm (the C++ 'version' of Gtk) is excellent, and I use it a lot when developing on Linux. I haven't even tried to set up gtk on Windows, but I hear it is a lot of work.

ftp://ftp.gtk.org/pub/gtk/v2.8/win32/

FLTK (fulltick) is what I use for cross platform GUIs. It has its problems, but it is *extremely* easy to get running on any platform, and your code should be very portable. If I am doing stuff with OpenGL I use FLTK, there is a lot less work involved in getting things up and running with it than there are with Gtkmm. The two are actually really similar, and if you can learn one then you will be very quick to learn the other.

www.fltk.org

I hear Qt is pretty spiffy. I haven't tried it too much myself, so I can't give an opinion on it.

-Fredric

My main beef with MFC is its resource editor

MFC (Microsoft Foundation Class) doesn't have such a thing as a resource editor. MFC is a library of functions, not a compiler or IDE.

MFC (Microsoft Foundation Class) doesn't have such a thing as a resource editor. MFC is a library of functions, not a compiler or IDE.

Sorry, I was referring to developing MFC applications, and I haven't seen anyone do it without that resource editor that comes with MSVC++ 6.0.. Seriously, do you know of any good tutorial or something that you could post that doesn't use that resource editor at all? It is a piece of junk.

-Fredric

what don't you like about it? just calling something "a piece of junk" is not very helpful. Do you have a better resource editor in mind? That's my opinion of QT too, but that doesn't mean it is no good -- it only shows my inexperience with the product.

Doesn't do bitmaps very well, but you can use other pait programs to create *.bmp files then import them into VC++ 6.0 project.

In my opinion, if you can sit down in a simple text editor, and without looking at any notes, write out the code for a simple application, then you are using the right libraries for the job. If you have to constantly look things up in a help menu or go to online tutorials, then you are using the wrong libraries for the job. If you can't write code that is self documenting, and understandable to someone who isn't familiar with the user interface that you are working with then that user interface is bad, and should not be used. In my experience this has been the doom of many projects that I have worked on with other people. They don't understand that 1000 lines of...

BEGIN_MESSAGE_MAP(CLayerTree, CTreeCtrl)
//{{AFX_MSG_MAP(CLayerTree)
ON_WM_CREATE()
ON_NOTIFY_REFLECT(NM_CUSTOMDRAW, OnCustomdraw)
ON_NOTIFY_REFLECT(TVN_BEGINDRAG, OnBegindrag)
ON_NOTIFY_REFLECT(TVN_KEYDOWN, OnKeydown)
//ON_WM_PAINT()
        ON_NOTIFY_REFLECT(TVN_ITEMEXPANDED, OnItemexpanded)
        //}}AFX_MSG_MAP
END_MESSAGE_MAP()

...is going to completely ruin your day when a bug appears. Why? Because this code is not expected in the middle of a supposedly object oriented program, it is not intuitive what is going on here, or why you are doing it.

Going further, if you ever want to change the way a control looks, you wind up with code that looks something like this:

NMCUSTOMDRAW nmcd = *(LPNMCUSTOMDRAW)pNMHDR;
    if ( nmcd.dwDrawStage == CDDS_PREPAINT )
    {
        *pResult = CDRF_NOTIFYITEMDRAW | CDRF_NOTIFYPOSTPAINT;
        return;
    }

What was that? NMCUSTOMDRAW? LPNMCUSTOMDRAW? CDRF_NOTIFYITEMDRAW? I don't know what that means without a walk over to www.msdn.com, I've looked them up before but for some reason long lists of random capital letters don't stick in my head too well, and they shouldn't have to. Let's have a look at this superior product's documentation, shall we? Here is the opening to the NMCUSTOMDRAW documentation at msdn:

NMCUSTOMDRAW Structure

Contains information specific to an NM_CUSTOMDRAW notification message.

Syntax

typedef struct tagNMCUSTOMDRAWINFO {
NMHDR hdr;
DWORD dwDrawStage;
HDC hdc;
RECT rc;
DWORD_PTR dwItemSpec;
UINT uItemState;
LPARAM lItemlParam;
} NMCUSTOMDRAW, *LPNMCUSTOMDRAW;

Jeez, thanks Bill. That's some informative stuff you got there. I really enjoy wasting 99% of development time going through infinite loops of long random capital random letters.

-Fredric

I have worked with MFC for sometime and then started Windows Programming with the pure C/C++ Code and the Win32 APIs. After that much of the things that were not clear in MFC became easier to understand.
All Win32 and MFC does is handle the Various Windows messages under some Event Handling Function. Once you get to know these events, the names given to the handler functions become clear, and you will see that the names are not that random as it initially seems.

For Example - The Prefix NM will denote Notification Message.
WM = Window Message
TVN_KEYDOWN is a specific window message sent from the TreeView ( Hence the Prefix TV ) and since this is of the form of a WM_NOTIFY Message, the Prefix is TVN. A Programmer who has spent some time in Win32 will know that this notifies when a User presses a key when the TreeView Control has input focus.
Similary if you look up the documentation for NM_CUSTOMDRAW you will understand what are the parameters that are passed in he NMCUSTOMDRAW structure. All depends on what you are conversant with.

Yeah in a way I agree with Daishi in that MFC is not that well structured. But this is not due to its resource editor, but the way it generates the Code. I however think that this can be cleared up to some extent if you did some pure Win32 API Programming.

I dont see why it is bad to refer documentation all the time. While we can get a rough idea of the Events that are to be used just by looking at them, with so many APIs in the Win32 Library and the MFC Libraries, I dont see how can one memorize all of them with all the parameters and such. And again I think ( IMHO )that the Win32 API is very well documented. Microsoft products are not that bad as it is said to be. :cheesy: But these views are very much dependent on the amount of practice you have on the specific library so no hard and fast rule as such.

In my opinion, if you can sit down in a simple text editor, and without looking at any notes, write out the code for a simple application, then you are using the right libraries for the job. If you have to constantly look things up in a help menu or go to online tutorials, then you are using the wrong libraries for the job.

Bullpucky! All you want to do then is write console applications. There is NO GUI operating system or set of libraries that are that easy to use. If you think MFC and MS-Windows is difficult, then switch to *nix and use X11 and Motif. or program for MAC os. Or if you want to use a simple text editor such as Notepad.exe then you should be writing HTML code, not C or C++.

Bullpucky! All you want to do then is write console applications. There is NO GUI operating system or set of libraries that are that easy to use. If you think MFC and MS-Windows is difficult, then switch to *nix and use X11 and Motif. or program for MAC os. Or if you want to use a simple text editor such as Notepad.exe then you should be writing HTML code, not C or C++.

Actually, I do write programs with user interfaces in emacs IN Linux. I use gtkmm, and fltk. They are extremely easy to use, understand, and I don't need to constantly check back through documentation which means that I can spend more time doing what I am actually doing. It is with my experience easier and faster to use these set of libraries then it is to use MFC or Win32. If you honestly think that there are no set of GUI libraries that are easy to use with C++ then you should really check out what is being mentioned, it will help you.

-Fredric

Actually, I do write programs with user interfaces in emacs IN Linux. -Fredric

Its really all a matter of gaining experience. gtkmm, and fltk may be easy for you to use because you have learned how to use them. MFC is (pretty much) easy for me to use for the same reason. I don't have to look up everything in MSDN any more either, but I'll bet we both had to do that when we first starting learning the libraries. So I think is not really a matter of "which is better, MFC or gtkmm", but of which one you want to spend a lot of time (in terms of months) learning. MFC has about a one year learning curve to learn it well. I have no idea about gtkmm and fltk.

gtkmm, and fltk may be easy for you to use because you have learned how to use them. MFC is (pretty much) easy for me to use for the same reason.

That may be true, but you should know that I had been using MFC exclusively for the past 3+ years...sigh... I had only found out about fltk and gtk within the past few months.

-Fredric

That may be true, but you should know that I had been using MFC exclusively for the past 3+ years...sigh... I had only found out about fltk and gtk within the past few months.

-Fredric

Could it be that I've been suckered (brainwashed) by M$ into thinking MFC was a great product :mrgreen: I write a lot of code for WinCE 5.0 so there isn't much choice for me.

This article has been dead for over six months. Start a new discussion instead.