Messages

Its not about adding functions, its about how the widgets handle the given text size themselves.
But since this looks like a pretty big change and since I don't have time anyway, I'm just going to not think about this again until July/August .

I can write such a getGuiTextSize function for you, but then you still have to apply it for every widget .

One of the problems is that every widget is different.
You gave a good example yourself with the ComboBox: you cannot set its size. The text size is calculated on the fly and not stored. It would take some work to allow setting a font size in every widget.
Then there is the unfortunate delay between creating the widget and adding it to its parent. If I would make the text size global then this is not an issue, but then you cannot have exceptions. It would be nicer is text size was determined by the parent so that you could have 2 child windows with a different text size for their widgets. But by the time you add a widget to its parent you could have already set a size manually and there is currently no way to detect that.

So its a lot harder on my side than just adding a global function and calling setTextSize on creation .

Changing all the existing widgets isn't that hard.
Changing all widgets that still have to be created is a lot harder. And not changing them is not an option because then every time you have to add a new widget you still have to set the size again.

Some widgets (like ComboBox) indeed do not expose the size of the text directly. It is automatically determined by the size of the widget (or in case of e.g. ListBox, the item height).

I though a little longer about it and having a setGlobalFontSize function is not that easy. It should be defined whether it adjusts widgets that are already created and/or widgets that are created later. Text size 0 is already reserved for auto-scaling so it would be hard to find out when the global size is used.
So it won't be a quick fix.

Edit: I am aware of that issue and its on the todo list.

I don't want to include it in the .conf file since it is supposed to contain theme-specific options (aka properties that are the same for all widgets and usually don't need to get changed in the code).

But the setGlobalFontSize sounds like a good idea. I'll add it to the todo list.

Sorry, I forgot to push the changes to github earlier. The changes are online now.

BTW: I hope you do not feel annoyed at my many requests.

Not at all, I'm always glad to see that someone uses tgui.
It's probably more annoying for you to constantly hit on a bug than it is for me to fix them or answer questions.

Small suggestion: Currently, when you tgui::Button::copy(aButton), the tgui::Button::connect(func) also gets copied. I think this is seldom what the user wants if he copies a button.

You have no idea how much work it cost me to be able to copy these signals .
This is indeed something that should be looked at. But I think I'm going to wait for more feedback and review this later.

As soon as I try to call setNormalImage() manually, I get a single unresolved external for it.

Sigh. Damn windows only bugs.
I have to write TGUI_API in front of every single class. If I forget it then you can't use that class with dlls.
It's should be fixed now.

(strange that I didn't receive a mail for your posts, luckily I have a habit of just checking the site regularly)

You can do this in v0.7 by accessing the renderer. It has functions for changing any property that was loaded from the theme file.

Code Select Expand

button->getRenderer()->setNormalImage("normalimage.png");

Of course you can still load a subrect of an image just like you can do in the theme file, but you should look at the documentation for the other parameters: https://tgui.eu/documentation/v0.7/classtgui_1_1ButtonRenderer.html#acb67846b97bd5b1e816e8d9e9f4ff612.

It think it would really come in handy to have a method that specifies how child widgets should be positioned

It can be done already with 0.7, but not in a very short and easy way.

TGUI 0.7 is the first version where there is some decent layouting, so its not really as great as it should be.
Its important to understand that the Grid widget was added in v0.5 to provide a simple way to put some buttons below or next to each other. It was never intended to be advanced and it has not yet been rewritten to provide more functionality.

With the layout system, this is how you currently would center a picture in the gui:

Code (cpp) Select Expand

picture->setPosition((tgui::bindWidth(gui) - tgui::bindWidth(picture)) / 2.0f, (tgui::bindHeight(gui) - tgui::bindHeight(picture)) / 2.0f);

Centering the grid in a panel will become:

Code (cpp) Select Expand

grid->setPosition((tgui::bindWidth(*panel) - tgui::bindWidth(grid)) / 2.0f, (tgui::bindHeight(*panel) - tgui::bindHeight(grid)) / 2.0f);

Of course it would be nice if it was simpler, most lines with these bind functions can get quite long, but this is the only way so far to do it.

PS: The layout system was not tested yet with complex widgets like Grid, I hope the code above will actually work.

You could create an extra boolean in your function, e.g. called "running".

If you e.g. want to change the running variable when a button is pressed you can do

Code Select Expand

button->connect([&](){ running = false; });

If your callback function contains too much code for being a lambda function you could pass the running variable by reference.

Code Select Expand

void myFunction(bool&);
button->connect(myFunction, std::ref(running));

Another solution might perhaps be not to have the main loop inside your state.
Your state should have the functions like handleEvent, update an draw while the main loop just calls these functions on the active state.

You are not meant to use multiple Gui objects (at least not on the same window).

If you would, each would have its own list of widgets and you have to call handleEvent and draw on the correct gui. So this is only good for when you have multiple windows as well.

In order to have multiple screens in a single window, you should use the Panel widget. You create several panels, each for the different game states. Then you hide all of them except one. When changing state, you just hide the visible panel and show another one.

In v0.7 you have to call the add function manually, which is why it is now possible to change it or even remove it.

The problem with v0.6 was that the add function was called automatically when the widget was created, since creating it and adding it the gui happened in one step. So the add function was already called before you could use the widget so an extra addWidget function was needed.

The Grid widget hasn't changed since v0.6 at all so far, which is why the initialize is still called inside the add function as it was required in v0.6.

I could do a quick fix with moving the initialize call to addWidget, so that you don't have to call the add function anymore. But without serious changes you will always have to ability to call the add function even if it doesn't need it for anything (due to the inheritance from Container).

Yeah, add is needed for inheriting the font while addWidget is needed for all the rest.

When rewriting the Grid widget I will make sure that you will only need to call one function, instead of both add and addWidget. This design was chosen due to the way widgets were created in 0.6, but in 0.7 I can change this.

I would have to check this to be sure but I think I know what goes wrong.

The font from the parent is given to the widget when you call the add function.

What I think happens is:

Code Select Expand

auto grid = Grid::create(); // Grid is created, has no font
auto button = Button::create(); // Button is created, has no font
grid->add(button); // button copies font from grid, but grid doesn't has a font yet
gui.add(grid); // Grid is given the global font here, existing widgets remain untouched

If this is the problem then you can work around it by doing this:

Code Select Expand

auto grid = Grid::create(); // Grid is created, has no font
gui.add(grid); // Grid is given the global font here
auto button = Button::create(); // Button is created, has no font
grid->add(button); // button copies font from grid, which had a valid font

The grid widget will be changed later in v0.7 to make it easier to use.

But right now you still need both the add and addWidget function.
I don't think I changed the bahavior so you should have a look at the v0.6 tutorial for Grid.

The add function in Grid is the exact same add function as the one in Gui.

So basically need both these lines:

Code Select Expand

grid->add(button0); // Add the widget to the (grid) container
grid->addWidget(button0, 0, 0); // Place the widget in a cell

On a sidenote, I use the grid widget for layouting, centering multiple widgets that is. Can I achieve this via bind methods also? I haven't looked into them yet.

You could indeed use the bind methods to achieve this. The Grid widget is a simple but limited way to set relative positions, the bind functions (and the entire layout system that those functions use in the background) is a more advanced way of having relative position and sizes.

Are you calling the addWidget function after you created the widget?
If so, could you show a small example code?

Good.

It was such a stupid mistake on my side in the end.
Last month I noticed that the include wasn't there. But when I took a look at v0.6 I noticed that it wasn't there either. So I simply didn't understand how my code was working, so I just added a note to my todo list to remind me of figuring out what was going on. Since it worked fine in 0.6 I assumed that it would also work in 0.7.
But the file was included in 0.6 as a side-effect of including SFML/Graphics.hpp and I had been minimizing these side-effects in 0.7 exactly to have more control about which include goes where. And ironically that lead to the missing include.

I wish there were free windows VPSs around to avoid these kind of errors. I have like 3 VPSs on which I can (automatically) test TGUI, but they all run linux. And I'm not going to pay $15 each month just to run some tests.

On the other hand, these kind of issues are very rare. Usually I don't touch this part of the code, so this probably won't happen again until 0.8 .

PS: Nice little edit in the chat box

I don't believe what I'm seeing here.
Its on the very top of my todo list: find out where the hell SFML/Config.hpp is included.

Due to some reordering of includes, this file was simply included too late, making OS detection impossible. Therefore the windows specific code for dlls was not defined.

All should be fixed now.

Ouch, the problem is probably on my end. I seem to have swapped some files and I apparently ended up testing v0.6 instead of v0.7-dev.

I was about to send you the version which I compiled earlier when I found out that it was 0.6.

So I will have to change my include directories and stuff again and run another test. I will most likely encounter the same problem as you then.

Could you send me the whole tgui folder that you currently have, with the build libraries included. And also the sfml folder (including headers and libraries) which you use to build tgui. You could also include the project that you have to build the example code. (e.g. on dropbox)

I'm not sure if I'm going to find anything since I wouldn't even know where to start, but I can at least try to look for some difference.

I don't have any problems with building the example code.
But my tgui-d.lib is 412kb so something seems wrong with your file.

I suggest you clear the cmake cache and try to rebuild the library, maybe that solves it.

While fixing the compilation on VS2013 I made a few changes with the placing of TGUI_API (which is a windows specific define that every library has to implement in order to use dlls) so I hope I didn't do anything wrong.

I'll test the example code myself soon. I don't like these windows specific issues because I can't really test them quickly. If it were reproducible on a linux it would be solved in a matter of minutes.

Pfff, I solved the problems. The latest version should compile fine.

But I'm walking on very thin ice with the VS support. I'm actually relying on that the compiler in VS being broken in such a way that my code still works.

I'm seriously pissed right now. Not only did my VS2013 compiler simply errored during compilation of a simple list initializer (which they claim to support), but even with update 3 I am going to have to remove functionality from tgui in order to support VS2013.

I'll try to get something working in the next few hours, but right now I'm not really happy with the only solution that I find.

Ok, I guess I will have to fix more than one line then.

I do want to keep VS2013 supported, if possible even without any updates, so this definitely has to be fixed asap.

Its just stupid that both gcc and clang already have excellent c++14 support while visual studio doesn't even support c++11 fully.