Containers refactoring cause some problems

Started by gupas, 06 August 2013, 20:27:14



You recently merged Container and ContainerWidget and updated Gui (creating ContainerGui). However, there are some bugs with the size of a ContainerGui when you (re)create the window subsequently.
For example:

sf::Window window;
window.create(sf::VideoMode(800, 600), "title");
tgui::Gui gui(window);
window.create(sf::VideoMode(1024, 768), "title");
gui->getSize(); // == (800, 600) !!!

PS: [Off-topic] Nice work on the ComboBox widget, I tested and it works great.


The problem is that the gui is only told about the resize when receiving the Resize event (by the way, is the resize event send after recreating the window on windows?).

I can solve this particular scenario, but it won't be completely solved.
If you have a button in the gui and then use button->getParent()->getSize() you will still get the wrong size.

Passing the window to the gui again should solve this issue, so maybe I should document it somewhere that you have to call gui.setWindow(window) after calling window.create(...)?


But why you don't store a Window* in GuiContainer? There is no sense to set an other size that the window size, so I think you should not store directly the size but a Window*. That will avoid this problem.


I slept on it for a night and I got the same idea.
I was planning to add a Gui*, but a Window* is even better.



Sorry to have prevented you to sleep :P

You can also find a usage to setSize: it could resize the window, but it can be a bit dangerous... An other possibility is to add an option bool setSizeResizeWindow which is false by default. (But it is only to find an interesting behaviour for setSize, I don't need this personally).


I'm just going to leave the setSize empty for now.
As long as the function isn't really needed I see no reason to implement it, as the whole GuiContainer class is just a workaround to make my design possible. If I ever find a better design again this class will get removed again.