Related association with ticket #333 was added

Raczej mechanizm konieczny, bez niego mechanizm lokalizacyjny może stracić sens bo wszystko będzie się rozjeżdżało, a i ciągla rekompilacja jest meczaca...

Proponuję następujący mechanizm:
- jest sobie plik, nie wiem, GUI.xml, z korzeniem <root>
- ten <root> odpowiada węzowi CRoot z kodu
- posiada on dzieci - <node name="..."> oznacza węzel dla dziecka o danej nazwie
- wszystkie węzly posiadaja wpisy o parametrach - <width-percent>...</width-percent> i tak dalej
- te parametry są przypisywane obiektowi tworzonemu w metodach CGuiObject::CreateX (np. każda podklasa CGuiObject implementuje wirtualną metodę Configure biorącą węzęl xml)
- tak wczytane parametry są defaultowe; potem mogą być w kodzie przeciążane (np. może być potrzeba dynamicznego ustalania pozycji - tak jest generowane CAbilityTree)

Oczywiscie, to tylko mój pomysl - tak myslalem o tym, gdy tworzylem ticket. Uznalem, ze za malo to opisalem, wiec wklejam powyzszy opis - ale jak masz ochote to zrobic inaczej, albo jesli sie okaze ze powyzszy pomysl nie dziala, to jak zwykle - wolna reka :)

Time: 404

tak zupełnie z innej beczki... może lua/python będzie lepsza tutaj niż xml? bindingi do buttonów, hint-hint....

na mocy #753 - albo ktos sie tym zajmie i zaassignuje na siebie, albo wontfixuje za tydzien

Updating tickets (#368, #370, #420, #529, #570, #578, #592, #609, #610, #613, #619, #627, #629, #636, #637, #663, #664, #699, #710, #732, #734, #738, #742, #744, #747, #411, #616, #634, #638, #661, #668, #697, #698, #719, #735, #168, #282, #340, #355, #365, #371, #383, #561, #642, #665, #700)

wontfix