It's not so much the GUI stuff that defeats me as it is the jargon, figuring out the build environment (since every darn GUI environment seems to require its own complex and fragile build setup). I tried out a bunch of different setups, editors, IDEs etc… And I actually got a couple of mini apps running.
- Con: It's C based, which isn't so bad, as the C++ is less well documented and I couldn't make much headway getting that up and running.
- Con: When I used Glade to build my GUI, I couldn't get either KDevelop or Eclipse to accept the project properly.
- Pro: KDevelop has a GTK project template, but I didn't mess with that (I'd like to be able to edit my UI with Glade)
I dabbled with Qt briefly, mostly under KDevelop, although the trivial Qt sample was also coaxable into Eclipse. But I didn't really pursue Qt. It starts out nice and simple, but it bloats insanely rapidly, and then I got stuck on trying to figure out how to create a draw space to do my own drawing into…
- Con: GPL license. I once met Richard Stallman when Desiree turned up at a curry house with him one night.
- Pro: Ample tools, integrated into KDevelop and support for the project in Eclipse
- Con: Bloat – for what I'm doing, Qt is waaaay overkill. I spent more time learning how to turn stuff off than how to do what I wanted to do.
When we were evaluating possible 3rd party libraries for a replacement game UI, we looked at commercial and open source options. We looked at WxWidgets but as tempting as it was, decided against it because it runs your application. Of course, you could use message passing and run the UI in a thread, but with the heavy CPU demands of our application, the UI would rarely get a chance to run. So we nixed it.
They've done a lot to conceal the complexities behind their toolset. You're launched straight into a lot of Macro usage, reminiscent of MFC but not quite as garish. It's fairly straight forward. I found myself tied up, though, in trying to get it to work with either KDevelop or Eclipse.
Eclipse insists on corrupting its dependency files every make, so I have to use clean+make instead of make each time, which quickly started to chap my ass.
- Pro: KDevelop has a complete basic-app template to get you started.
- Con: Official documentation tutorials are mostly dead links.
- Con: Eclipse didn't like the "wx-config" way of getting the include paths and libraries, and they are pretty installation specific, making the project itself very unportable, not that it matters.
- Con: Like MFC, wxW is the application.
Yeah, I know, not a bad thing for a UI tool, but really forces me to write my project as a graphical application, when really its a non-graphical application with visual output. I'm not trying to become a UI programmer, all I want is to add visualisation to something I want work on. Maybe some controls to pan around/zoom, but pretty much just drawing colored dots over an image, hehe.
Conclusions and progress
The quagmire for me is that I don't want to learn a complete graphical toolkit, and it seems virtually impossible to find a tutorial or library that isn't front-loaded with the assumption that you care about the different types of window border styles on 8 different platforms :)
I'd be more than happy to settle on a Linux-specific toolkit :)
Anyhow – I made the most progress with wxWidgets. Actually got a little app up and running that would take a batch of data and render it.
In the end I made most progress with WxWidgets, but I have the suspicion that where the other two were front-loaded with obstacles, WxWidgets is going to be rear loaded.
I'm thinking that, if all else fails, I'll integrate it with Raknet and then write myself a headless teulKit black box that will also accept a Raknet connection and send the data to my client. It's way more work than this seems to warrant, but networking stuff I don't find nearly as intimidating as these graphical toolkits.