I’ve kept this in the back of my mind when creating it – this is why the stuff that does the actual work all sits in its own set of files/classes, as opposed to being totally intertwined with the GUI window.
As for abstracting the GUI itself away – I feel this is rather silly – the whole point of wx is to be cross platform (in fact, it uses GTK in Linux), and trying to abstract over that (which is already an abstraction) is just a bunch of unnecessary work that I didn’t feel was necessary.
Besides, 90% of the code in the GUI window is just fluffy glue that moves information from the GUI controls to the control interface class (and vice versa). There isn’t really any real work involved there.
You have to draw a line somewhere, and I placed my line in the Simulator directory classes. Feel free to draw the line somewhere else though, and send a patch. 
Also, what if someone wants a console interface to the simulator? I’m more than willing to help on this front; it looks like you only need thread synchronization from wxWidgets, which is very easy to port.
You’re more than welcome to separate out the synchronization stuff, it should be quite trivial to do. There is also a line in Simulator::SimulateStep() that sends an event to the main window, I suspect that could be abstracted away quite easily, in the same way that the synchronization stuff would be.
A better approach in the long run, although more difficult, would be to implement the FPGA interface (the ChipObject classes and whatnot) rather than editing WPILib directly. Then WPILib can be run directly without need for modifications (that can easily be buggy).
A good number of the WPILib classes don’t depend on anything in the hardware, and so I’ve tried including those verbatim when possible (though, it wasn’t my original goal to do this so some of the objects have a lot more chopped out of them – my point of view on this evolved as time went on). At some point I will probably go back over the classes and reevaluate how I chopped them up – one in particular that should have been done better is the chopping of DigitalModule/AnalogModule.
You will not be able to get it done totally unmodified, due to some compiler quirks (for example, Visual Studio will not allow you to have non-integer static constants). Also, due to the looping nature of the code, you have to find somewhere to stop the loop, so modifying IterativeRobot and SimpleRobot is necessary (a very tiny modification in each).
The downside of abstracting at the fpga class level is that all of the ChipObject stuff is totally undocumented (even though its typically obvious what the function does), and is subject to significant change at the whim of the fpga designers. I felt abstracting at the WPILib level was subject to less change, and would be easier.
Of course, feel free to do it differently. Send patches.
Another good thing to implement would be a unit testing framework for WPILib.
If you’re talking about WPILib itself… well, I would hope they have some kind of testing that they do for it that they just don’t give to us (but, thats probably not the case).
If you’re talking about using this to create something that you can unit test your robot code in it, then I would agree thats probably a good thing to do. I don’t have a ton of experience in this area, so I would rather defer this work to someone who has a better idea of useful things a unit testing framework should have.
