C++ GUI (or how to lose precious hours)

As stated previously, I'm working on a terrain generator with the SFML (more details on that later). But now that the core thingie is running, I'd like to add a GUI to tweak the parameters.

Foolish me. I had no idea what I was getting into.

So. I know we're going to delve into Qt later this year, so I wanted to use Qt. But building under VC2010 sounded like a pain in the - er - back, so I looked elsewhere.

wxWidgets looked rather nice. Bummer, no VC2010 version. But wait, wxPack is a compiled version, with VC2010 compatibility! Well, uh, not quite. It doesn't integrate so linking is really painful, specifying every library by hand with no data on the required ones (and trial and error is really annoying beyond 20 libs). Integration works with the 2008 version though. Which is (completely objectively) less pretty and comfortable, and doesn't highlight matching braces on reading. Using wxWidgets also involves really ugly-looking macros absolutely everywhere. And I dislike having 400 warnings coming from the libs during linking.

Back to Qt then, using QtCreator? I guess. Except no. The installer seems to have messed up and not installed project files. And the package manager refuses to find some component's metadata. So on I go to download the offline version.

Meanwhile (1.4GB takes quite a while to download), I look around for alternatives. I had heard about GTK+ but forgot to investigate. Saw a C++ wrapper called gtkmm. Download. Install. Add properties sheets for VC2010, included in installer. Write some example code. Build. Run. One small warning. Running smoothly. And one small but lovely detail: a "Side Effects" section in the installer, stating the modified environment variables. That's too rare.

Qt wasn't even done downloading.

So I guess I'll stick with gtkmm. No ugly macros, easy install, multiplatform. What more to ask for?

(Edit / Spoiler: easy GL context creation? One cannot have it all... We'll see how it ends.)

Enabling SFML under Visual C++ 2010

I'm writing this because (at least for now) the SFML is "only" available for Visual Studio 2005 and 2008, plus MinGW. Yes I could use free software, but the whole point being to get familiar with Visual Studio, that would be a shame. So, SFML and Visual Studio.

First things first: in order to avoid compatibility issues, you have to recompile the SFML. Follow these steps:

  • Download the full SDK at this address: http://www.sfml-dev.org/download.php.
  • Extract it in a directory which will be the permanent location of the library.
  • Open SFML.sln, located in build/vc2008.
  • Visual Studio will offer to convert the project. Click "Next" until it's done. There will be a few errors: it's not a big deal, they're in the examples.
  • Remove all projects with do not begin with "sfml-" from the solution.
  • Then build the four targets: Debug DLL, Debug static, Release DLL, Release static (pick from the drop down on the upper left).
  • Everything should build fine: close the solution.
  • The build created lib files in lib/vc2008: I replaced the ones at the root of lib with these new ones.

In order to link the SFML to a project, two steps are required. First, Visual requires the library's location. Go into the project's properties, Configuration Properties, VC++ Directories. In the drop-down menu on the upper left, pick All Targets, and:

  • In Include Directories, add the include directory from the SFML location.
  • In Library Directories, add the lib directory from the SFML location.

The second step is to tell the linker which libraries to use. Go into Configuration Properties once more, Linker, Input. Then:

  • For Debug configuration: indicate the libraries you use, looking like sfml-...-d.lib
  • For Release configuration: indicate the libraries you use, looking like sfml-....lib
  • If you want to link statically (embedding in executable) instead of dynamically (DLLs), you must use sfml-...-s-d.lib and sfml-...-s.lib.

If you're using dynamic linking, you'll have to copy the required DLLs (both debug and release versions) in the project's directory (not the solution's).

And if I haven't forgotten anything, your project should build and run just fine. Visual will protest about missing PDB files in Debug configuration, but it's not an issue. At first, I forgot to replace the files in lib with the ones in lib/vc2008 and the program worked in Release but not in Debug mode ("Application failed to start correctly, error 0xc0150002" or something like that).

With all this in place, and using the tutorials here, I quickly obtained a window with the infamous spinning cube. I'm now building a small terrain generation demo, but the details will have to wait a little ;)

Setting up...

Well that was interesting. Let's sum up how miserable I was in the course of the last two days, and hope it can help some people not be as miserable (or laugh at me, who knows).

  • Finding a way of accessing my OVH hosting though SSH: not as easy as it seems in their guide. They say one can indifferently connect to pro.ovh.net or to one's own domain? Well I didn't, ever, managed to log in pro.ovh.net. Had to use my domain name.
  • Setting up wordpress: no problem, nice and easy. Uploading some files through Filezilla (since OVH won't let users access the internet from SSH), creating a database, launching a script. Not too hard.
  • Setting up SVN: the OVH guide about that one is correct, at least. So you can follow it (french): http://guides.ovh.com/SVNMutu. A good thing to know: if (like me) you are some kind of barbarian and use Putty's exe file instead of installing it, "loading the key into Pageant" is not as simple as a double click, don't forget to map the "Putty key file" file extension to Pageant first. And, at least under Windows 7, the "icon in the lower right corner" does not appear, except in the notification area.
  • Setting up websvn: no problem either. Again, uploading, unzipping, setting the svn root directory in the config.php file (which doesn't exist! You have to copy include/distconfig.php to create it).
  • Adding authentication to websvn: now that was fun. Took me three hours. Every tutorial I stumbled upon used some Apache-specific features, which I apparently didn't have on my hosting. I finally quitted the idea of doing something clean, and made a very simple .htacess in the websvn root directory (four lines: AuthName, AuthType, AuthUserFile, Require valid-user) and a .htpasswd (which isn't in the accessible web directories of course ;)). The drawback is I can't filter acess by repository with this technique: but heck, it's better than having everyone viewing my SVN repositories.
  • Finding out WebSVN has messed up with PHP version and broken WordPress and fixing it, i.e. adding SetEnv PHP_VER 5 at the beginning of WordPress' .htaccess.

Next step is integrating a bug tracker (I'm thinking of Mantis). We'll see how it goes, I have all the time in the world.