PagedGeometry, sure, lets leave that (although I do revert/recompile often).
Unless you recompile everything, including unchanged files, that shouldn't matter, since those files aren't changing much...
Unused variables: I don't mean assigning in an expression
But rather wonder should I do some similar code clean up along the way. Example attached (remove unneeded variables, positive conditions, don't add wrong values).
The presence of the unneeded variables don't really hurt anything, and arguably makes the code easier to read since one doesn't need to look up functions like GetHullType to know what they're returning, but I don't really care either way if those are or aren't temporarily stored then discarded after the if checking the return value.
Positive vs. negative conditions doesn't really matter... I don't think it's worth going through just to change that just out of preference for positive. I usually use whichever of positive or negative works, and in these cases I was only outputting error text when the part or hull wasn't found, and was adding the passed-in name in either case, so the negative condition worked best.
Not adding the names of nonexisting parts or hulls to empires is changing how the code works, so isn't really cleanup anymore. When things are working, it shouldn't make a difference, but it might be helpful when debugging to see what part or hull name was actually added to an empire, without needing to have working log output, in case that name was corrupted or somesuch.
Also was considering "const"-ing, correcting case etc., I guess I'll just correct whatever comes in the way -- let me know if I start to overdo that.
These changes are fine. I often get nitpicky when rewriting some code.
CUIDraw: Considering that (if it could at all happen
there is an uninitialized access just after that default statement, are you absolutely sure that this message would be logged before the segmentation fault? Due to the possibility of compiler reordering that's not so obvious to me (although probably yes in this case, but with a bit of luck):
OK, I moved the default case above the SHAPE_RIGHT case, without a break between them, so the default is the same as SHAPE_RIGHT and things should get initialized fine.
I've noticed that expand buttons don't fit in InfoPanels if the font is made smaller, here's a fix (makes the population/resource/military panels at least as high as the button).