Re: gtk on win32

[LRN <lrn1986 gmail com>]

On 30.03.2010 11:26, John Emmas wrote:
>  Certain things like XP
> themes don't really work (as others have pointed out) and it's a great shame
> that bug reports aren't dealt with more conscientiously. Having said that,
> actual bugs are relatively few in number and GTK+ does have its own theming
> model (although I'm not sure if it's implemented in the win32 version).
>   
Last time i checked - it was (to some extent). Some GTK+ installers for
windows will even add "GTK+ theme switcher" application to your
application menu. It will switch default GTK+ theme for you, although
i've never used that.
> After a year or so developing with GTK+ I'm torn between whether I prefer
> GTK+ or MFC. GTK+ probably has the edge - especially so if your apps will
> need to run on other platforms. Make no mistake though, it's conceptually
> very different from MFC and you might find it frustrating at first.
>   
It's conceptually superior. MFC is, basically, a shiny wrapper around
WinAPI (with blackjack and whores). The concept of widget containers
alone is enough to switch to GTK+ (or any other toolkit that employs
such concept) away from WinAPI. And don't let me start talking about
treeviews...
> Another consideration is which compiler you're intending to use. GTK+
> probably works best with minGW (although I've never used minGW, so that's
> just a guess). Personally, I use it with Visual C++ where (with care) it can
> be made to work quite acceptably.
Despite being Linux-originated, GTK+/GLib works well enough with MSVC.
>  And VC++'s debugger is light years ahead
> of minGW's gdb. It's worth persevering with VC++ simply for its superior
> debugging.
That depends. While gdb's console interface lacks finesse (especially
when you're using it from Windows console!) it does have some nice
features that i am yet to find in MSVS. Also, it might be possible to
use GUI wrappers, such as Code::Blocks.
The real problem with debugging is debug symbol incompatibility. If you
mix binaries compiled with different compilers, your ability to debug
will be diminished. That is why it is better to use single compiler for
as many things as possible (application, supporting libraries).
>  But if you're planning to use anything later than VC++6, expect
> to encounter some problems unless you're willing to rebuild GTK+ (and all it
> s dependencies) yourself. In my experience (I'm using VC++8) '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?