|
-------Original Message-------
Date: 30/03/2010 08:54:19
>>
>> Make no mistake though, it's conceptually very different
>> from MFC and you might find it frustrating at first.
>>
> It's conceptually superior.
>
Well, that's a matter of opinion but in general I think I'd agree - except to say that MFC is undoubtedly simpler to use. To the novice, GTK often seems to make you jump through hoops to achieve relatively simple things like widget spacing (which is far simpler using Visual Studio's "resource compiler"). Also, a GTK newbie can waste a lot of time by not realising that he needs to call "init()" functions, prior to using certain aspects of glib and gtk.
Signals are a good example of where GTK offers greater flexibility than VC++. And yet there's a lot to be said for Windows messaging. In particular, messages make it much easier to be sure that work will get carried out in the right thread. A common mistake among inexperienced GTK programmers is to think that they can use signals where (in MFC) they would have used messages. But you soon find out (the hard way) that you can't!! Inter-thread communication might be more flexible using GTK but again, it's simpler using MFC.
>>'g_usleep()' seems particularly problematic for some reason
>> and I avoid it like the plague. Everything else seems to work
>> fine though.
>>
> Might have something to do with CRT incompatibility?
>
Yes, that's what I've assumed. At some point I'll rebuild GTK+ using VC++8 and see if the problem goes away - but it's not a task that I relish. I can't help thinking that I'll probably introduce more problems at the expense of fixing just one!!
Cheers,
John | 