One of my primary goals with Threatened Destiny is that I won't hard-code behaviors and objects, even for testing purposes (if I can avoid it).  That means that the editor has to lead the game, certainly at first anyway.  Since TD is built with SFML, it makes sense that the windows in the editor that represent the game should also be in SFML, but the need for an editor to have a "traditional" GUI makes me not very eager to write the whole thing in SFML, even though there are some GUI libraries for SFML which I'll probably use in the actual game.

Specifically, I'd like the usual sort of menus, split screens, and tabbed representations that we see in normal applications; which makes Qt or wxWidgets a natural choice.  I decided I'd run with wx; I've had slightly more experience with it, and the SFML site has a few examples of wx/SFML integrations on it.  That meant it was easy just to take somebody else's work instead of having to reinvent this particular wheel (yes, I do actually pick-and-choose which wheels I care to reinvent).

Turns out there are some gotchas with this (I'm using the wsSFMLScrolledWindow from the wiki, but these would probably crop up with the panel tutorial too).  First and most important; SFML RenderWindows don't resize the way you think they should.  When you resize the window (RenderWindow::setSize()), it tells the RenderWindow that it has a new size, but (my guess is due to the complexity of changing an OpenGL context's size) the window doesn't actually change its size yet.  The window has been notified of its new size, but it can't take the new size on its own; you have to recreate the window, just by calling RenderWindow::create() again.  An important note is that this can cause the scroll bars to move around, if you have them always drawn and the RenderWindow is smaller than the container window's available area.  (That is, instead of drawing the scrollbars at the edges of the available area, it moves the scroll bars to the outside of the drawable area; which is probably more correct anyway.  I'll worry if this is actually a problem once I have a RenderWindow that is larger than the available area -- the far more common case than what I have now).

Another snag is that, at least when you're dealing with a RenderWindow which is smaller than the available wx ClientSize area, when a resize event fires, the SFML View is resized.  Which is all well and good and correct...except that it is trying to project the same size RenderWindow in a new, larger view, rather than believing that the area it should be displaying is larger.  That causes scaling and "stretching" in the appearance of the RenderWindow.  This problem can be corrected by recreating the RenderWindow in the resize event again. That seems to prevent the RenderWindow from stretching due to the change in the wxClient area.

One big issue that I'd struggled with for a few days was that the RenderWindow seemed to have some very strange drawing behavior.  When I'd draw into the RenderWindow, it'd move (0,0) somewhere into the middle of the allowable space in the containing wxSplitWindow frame, and it'd draw the whole side of the frame black (as though the RenderWindow had suddenly taken up the entire frame, except that the rectangle of the RenderWindow wasn't the size of the whole frame).  When the RenderWindow was simply allowed to be constructed, but nothing was drawn to it, it'd be the proper size with (0,0) in the upper-left hand corner.  I did some experimentation based on a conversation from the SFML forums between a guy with a similar problem and the guy who created SFML.  By calling getDefaultView() after I recreate the RenderWindow in a resizing situation (specifically when I initially resize the drawing area for my grid), I guess I refresh the default view of the RenderWindow to match the window's new properties.  It still turns the whole containing frame the "clear()" color, but that's a pretty minor issue; the important thing is that it now actually places the drawing at the correct (0,0) location.

I also finally finished my math for drawing my gridlines.  Why am I doing math instead of just tiling an image?  Because I'm not that bright.  Also, I want to be able to dynamically grow the map area during editing, and I feel like actually drawing the lines might make that easier.  And since I'll have to do a bunch of math to determine the square grid locations of tiles on my isogrid, familiarizing myself with the isogrid math is probably a good idea.  (As I mentioned before, I'm planning to use a classical 2:1 symmetric axiometric perspective, what we gamers usually call "three-quarters isometric" or a really common form of "2.5D")  For a long time, I had a mostly accurate but somewhat buggy implementation based on my intuitive grasp of the isogrid.  The other night I actually went to the effort of reviewing my trigonometry and building the correct math formulas.  They turned out to be extremely similar to my intuitive version, I'd just messed up some of the line calculations.  Now that the isogrid is drawn, it's time to turn my attention to the actual image tiles and containing tilesets, and then I'll be able to actually generate a map.

I suppose I should start considering if I can develop a Boost::serialization setup for my desired data formats, and if I'll code the serialization or try to use introspection to automatically generate the serializations....