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? _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
