Messages

2.
You can use "button->setEnabled(false)" to disable the button which makes the button unclickable, but that might also change the look of the button depending on the theme, which might be undesirable.
One other thing you could do is temporarily disable the signal callback with "button->onPress.setEnabled(false)".

3.
Does each state have its own Gui object, or is there only a single Gui object that is shared between all states? (it is recommended to only have a single Gui per window)
Every Gui object contains a std::chrono::steady_clock which starts counting on the first call to draw(). Any calls you make to draw() afterwards will check the elapsed time since the last draw call and update animations with this amount of time.

So it sounds like when you go back to the previous stack, the elapsed time passed to the widgets is the entire time you spend within the last state, and hence the animations finish immediately. But that would only be the case if there was a Gui per state.

There might be multiple solutions to this (e.g. manually control the time of TGUI instead of letting the Gui handle it), but I would first need to better understand how things happen exactly before I can make suggestions on how to fix this.

I seem to have missed this topic somehow. Do you still have those questions?

I'm guessing there is some incompatibility with the libraries used, or a bug that only occurs in specific versions. I'll need to check if I can reproduce the same issue here.
Which parameters did you set in cmake to build TGUI?
Which versions of SDL and SDL_ttf are you using?

I've been able to reproduce this, I'll look into the issue.
Considering even the 0.9.1 release seems to suffer from this issue, I'm assuming it was introduced by an update in one of TGUI's dependencies (most likely SDL_ttf). Text rendering in TGUI 0.10 seems to still be fine (in all backends), but this is because it uses a completely different method to render the text.

Note that for the SDL backend, I do recommend using TGUI 0.10 instead of 0.9 as it has seen some improvements to its backends and it supports both an SDL backend with OpenGL (like the 0.9 backend) and one that uses SDL_Renderer.

Update: While I don't know what caused it to break in the first place, I have fixed the issue in the 0.9 branch on github.

You may also be able to use the setScale of widgets as alternative to sf::View.

An image with width and height equal to 4096 is 67MB. The next image size of 8192 pixels would consume 270MB. But I wonder if the texture really reached 8K, because even a 4K image would be hard to fill even with letters of 100 pixels.

Where you using a text size above 100?

Do you have a graphics card with dedicated VRAM, or integrated graphics where the GPU has to share RAM?

I should find some way in the future to not keep all the old glyphs around (which is tricky to do without creating unexpected stutter), or maybe I can add a function to explicitly clear the font memory (which would come with a serious performance hit when rendering the next frame). Because right now if the font texture grows too large, the GPU will no longer accept it and no more text will be rendered. The main reason I haven't fixed this yet is because luckily this is unlikely to happen realistically.

How drastically are you talking about, can you provide some numbers? Doubling can happen, but only if your program isn't using that much RAM in the first place. How are you checking usage? Tools like Window's task manager aren't accurate, they might show memory that has been reserved, not exact usage.

What is the maximum text size you are using?

Both SFML and TGUI store an image with all the character glyphs that have been loaded by the font (SFML doesn't allow me to access some internal things, so TGUI duplicates some of the memory).
When changing the texture size, all letters displayed on the button have to be loaded by the font and added to this font texture.
When the texture is full, a new texture is allocated with 4 times the size (twice the width and twice the height). This is the moment where you can see some memory growth, but it doesn't happen again until that texture is filled as well.
There is currently no way provided to clear the cached texture, it only keeps growing as long as you keep using new characters at different text sizes.

If the memory usage is due to the font, then this will only happen the first time. If you have a back button in your program and show the buttons again, clicking the same button should no longer increase memory usage, as all those characters are already loaded.

You are attempting to create a tgui::Font object before the Gui object has been attached to a window.

One issue with TGUI supporting multiple rendering backends is that it complicates the initialization and destruction a bit. All TGUI objects (except a root Backend or Gui object) have to be initialized after the backend is created, and have to be destructed before the backend is destructed.

By default, TGUI hides the backend with the Gui class. Unless you explicitly construct a backend object in your code (which you probably shouldn't do), the backend will automatically be created when m_gui.setWindow is called and this backend would be destroyed when the (last) Gui object is destroyed.

If a TGUI function is called while the backend doesn't exist (not yet created or already destroyed), then you will get a "getBackend() was called while there is no backend" assertion (the getBackend() function is being called by the constructor of tgui::Font in the Class Game constructor this case).

The debugger can provide you with a call stack that shows where in your code such error occurs btw, in case you have trouble finding where the error is coming from in the future.

One place you can also find which renderer properties exist for a widget without looking at the source code is the documentation for the Renderer class (e.g. ButtonRenderer: https://tgui.eu/documentation/0.10/classtgui_1_1ButtonRenderer.html), but the source code itself might still be clearer.

I intent to add a guide for each widget to the tutorials, which amongst other things would include a list of its renderer properties. That would make it easier to find that information. This has technically been on the TODO list for many years already, but I'm planning on actually starting with this once I have the Release Candidate for upcoming TGUI version ready.

The Theme::load function has been fixed in the development version in the meantime btw, which solves issues in case you would be removing properties when editing the theme (otherwise there is probably no need to update TGUI).

Apparently the code I was testing with was slightly different. There::setDefault only affects new widgets, not existing widgets, so you would need to recreate your widgets. The following code works, but not perfectly:

Code Select Expand

tgui::DefaultThemeLoader::flushCache();
tgui::Theme::getDefault()->load("data/TGUI/theme.txt");

It will change the renderers of existing widgets, but it doesn't seem to reset some properties: e.g. the old theme has a border and the new theme doesn't have a border, then the widget will have the look of the new theme but with a border. So this is a bug that I'll need to look into.

Edit: The bug in the load function is a small mistake, using getDefault()->load will soon work properly for your use case.

Are you calling widget->getRenderer() anywhere? That would disconnect the renderer from the theme so that tgui::Theme::setDefault will no longer update that widget.

TGUI indeed assumes that a theme file doesn't change at runtime. It caches the file contents when it reads it the first time. This is undocumented behavior, but you can clear the cache by adding the following line of code:

Code Select Expand

tgui::DefaultThemeLoader::flushCache();

The static flushCache function can be given a filename as parameter if you only want to remove the cache of a single file instead of all theme files.

50MB is normal for a debug version. Just the "libtgui-s-d.a" is 91.6MB (while the release version is less than a 10th of that size). Dynamic linking results in smaller exes because it keeps all the external code in the DLL instead of including it into the exe.

Did you build SFML and TGUI yourself using the "SFML_USE_STATIC_STD_LIBS=TRUE" and "TGUI_USE_STATIC_STD_LIBS=TRUE" options?
Because the default static SFML and TGUI versions link dynamically to libgcc and you thus shouldn't have "-static", "-static-libgcc" and "-static-libstdc++" in your linker settings.

The build log does tell you when you are compiling and linking, but I just tried it here and it is less useful than I thought.
All the lines starting with "g++.exe -std=c++17" are telling you that it starts compiling a source file (at the end of the line you can see which source file). These lines can print very quickly when building with multiple threads, as it will start compiling multiple files in parallel.
The last "g++.exe" line which is longer than the rest and ends with all those "-lXXX" options is when it starts linking the executable.
I was surprised that it is printing compiler warnings AFTER the linking step. All compiler warnings should happen before it starts linking. But I tested it here and this seems to be normal when you don't explicitly set the number of parallel builds to 1. And while the text is outputted in the correct order when doing so, it's still hard to follow what it is doing in realtime.

At the end of the build log it states "Process terminated with status 1", which means it FAILED (it should end with status 0 normally). Did you manually stop the build? Because if you didn't do anything then I think it might have crashed (which would be weird if it does still generate a functional exe).

That doesn't sound normal. Up to a few seconds more compilation time (potentially multiplied with every source file that includes TGUI) and up to several seconds of additional linking time might occur in worst case, but over a minute is far too long. Since there shouldn't really be a difference between static or dynamic linking, especially the compilation time of the source files should be identical, you should see the same slowdowns when linking dynamically though.

The Build Log at the bottom of CodeBlocks will tell you which file is being compiled and when it is linking the executable. The first thing you might need to do is check if the linking step that is taking more than 10s, or whether the majority of the time is spend on compiling files.

In 79 seconds you can compile the entire TGUI library, are you certain you aren't compiling the TGUI source files with your project?
And you didn't enable Link Time Optimization (which would add a significant amount of time to linking)?
Are those TGUI headers being included in a single source file, or in a header file that is included in many source files?

I've never created anything complex with my own gui, so I can't give much advice. I would go for whichever method is easiest to implement, which I imagine is probably to render the game and gui separately and determine which of the two has to handle the events you receive.

The gui.handleEvent function returns a boolean whether TGUI handled the event. While there might be complications in more complex cases, it might be a good starting point to try passing the event to TGUI and handle it in your own game when TGUI discards the event.

1. Use TGUI as the base graphical engine and use canvas for drawing the game itself

I wouldn't draw anything to a canvas unless needed, and instead render directly to the window.
TGUI renders all widgets at once, but you can draw whatever you want before or after it. A CanvasSFML class exists to render your content to the canvas and then let TGUI draw the canvas together with the widgets, but it's only use case is to allow custom rendering inbetween widgets (e.g. draw inside a child window). As long as your content is below or above TGUI, there is little reason to use the canvas.
Rendering either your own stuff to a TGUI Canvas, or rendering TGUI to your own kind of canvas will both work to have the game and UI drawn separately in fullscreen, but they only add unnecessary draw instructions when you can draw both directly to the window.

2. Game graphic integrate with TGUI as widgets

There might be a few cases where this might be helpful (e.g. use Picture widget instead of drawing your own sprite so that you can use the onClick callback instead of writing your own code to check if the sprite was clicked), but in many more complex cases I think this will complicate things. If an object is not a UI widget (or clearly acts like one) then it probably should be handled in your own code where you have full control over it. Trying to turn everything into a widget will add boilerplate code and might make it more difficult to handle all events.

Of course it all heavily depends on the type of game. If it almost exclusively relies on mouse events then you might be more easily wrap graphic objects as widgets, but if you need to handle keyboard events then you might be much better off implementing things in your own code.

it does not unfocus Editbox / does not end editing

This is correct, the edit box doesn't actually do anything when you press enter.

The onReturnKeyPress and onReturnOrUnfocus are signals (like onPress in Button widgets) that you can connect to so that you can receive a callback when enter is pressed while the edit box is focused. So they just inform you about the key press, and don't change the state of the edit box.

The only reason why onReturnOrUnfocus exists is that there are many cases where you may want to execute the same code for onReturnKeyPress and onUnfocus, and the onReturnOrUnfocus signal simplifies this slightly (otherwise you would have to connect a callback to both onReturnKeyPress an onUnfocus, while now you only need to connect the callback to onReturnOrUnfocus).

You can connect to the onReturnKeyPress signal and then unfocus the edit box (or focus another widget) yourself from inside the callback if you really want that behavior.
I've never really though about how the focus is supposed to act when hitting the return key. I've only used if for cases where it triggered the same callback as a button beside the edit box or validate the input inside the edit box. I've never cared/thought about the focus before, so I never implemented any behavior for that.

You can find the other widgets by scrolling through https://tgui.eu/documentation/0.10/annotated.html (which is a list of all classes, not just widgets)

Something like list of widget with simple screenshot or at least just list of widgets?

Creating such a list (with a screenshot, minimal explanation and a list of its signals) has been on my TODO list for a long time. I'll probably start working on it once 0.10 is released.

Edit: The default theme code could also be used as a list for all widgets for now: https://github.com/texus/TGUI/blob/0.10/src/Loading/Theme.cpp#L40-L303