GG::Button -> CUIButton

[Geoff the Medio]

This commit replaced various GG::Button with CUIButton.

In several cases, I don't see the benefit to the changes, and do I a downside to doing this, as CUIButton has some of its own member variables (m_border_color, m_border_thick) which aren't used or needed for the cases where a GG::Button was being used. Switching to the now-parameterless constructor of CUIButton also requires multiple additional function calls to set sizes or colours.

Why do this?

[adrian_broher]

In several cases, I don't see the benefit to the changes,[…] Why do this?

The same reason I did the other CUI* related commits: to deduplicate and simplify code. All those GG::Button instances are called with the same parameters or parameters that are actually overwritten by a latter member function during the containing parent initialization. The CUIButton creates buttons with the most common parameters values within the FO code. I consider it more useful to adapt the instance to the local use case by setting the diverting parameters with a setter.

and do I a downside to doing this, as CUIButton has some of its own member variables (m_border_color, m_border_thick) which aren't used or needed for the cases where a GG::Button was being used.

I consider the additional 200 byte during runtime for all these instances a smaller issue than duplicate code. Also following the argument I could ask why GG::Button has a text attribute inherited by TextControl even if the instances you mentioned never display any text.

Switching to the now-parameterless constructor of CUIButton also requires multiple additional function calls to set sizes or colours.

You're right about the size, most of the time they aren't even needed because the parents does the layout afterwards. I just didn't realized this at the time I commited this change. The color seems to be a required prerequisite for rendering icons. I haven't the time to check why it is needed but I'm sure this can be removed after fixing some code.