Messages

I'm very biased in this because I always want to recommend using the very latest version simply because it has a lot of improvements (and because 0.7 feels old to me, from my perspective it is something from 2 years ago as I started working on 0.8-dev soon after the release of 0.7.0). But the downside of using 0.8 is that you will have to update your code when I make changes (e.g. I'm currently replacing show() and hide() functions with setVisible(bool), so you would have to update these calls after I release the changes). So you should have to decide for yourself.

The 0.8-alpha release is expected relatively soon (it could easily take more than a few weeks with my current progress though) and this release kind of indicates that the largest rewrites are done, which is actually already the case. There are no more planned changes that would affect the entire codebase, just smaller rewrites like the show/hide change, changing the way the user can resize a ChildWindow, etc.
Progress is going slowly, so I wouldn't wait for the final 0.8.0 release, it may still be many months away.

I can't guarantee that there won't be any large changes anymore though as I don't have a todo list for things that are going to happen after 0.8-alpha has been released. But I actually want to get 0.8 ready as quickly as possible, I don't want to spend another 2 years developing it (as it would mean that in e.g. 1.5 years from now there would still be people downloading the older 0.7 release).

Bug-wise, 0.8-dev should be just as stable as 0.7. There might be some more bugs in the new parts simply because it has been used less, but this is partially compensated with many more unit tests in 0.8. Plus any known bug is fixed practically immediately anyway in either version.

It looks like you would need TGUI 0.7.6 unless you make a small modification to the cmake script.
SFML made some changes in their dependencies in their github version. If TGUI detects version 2.5.0 (which doesn't exist yet) then it will expect the new dependencies while otherwise it will search for the old dependencies. This patch was only made in TGUI 0.7.6, so if you use an older TGUI version or you don't set the SFML version number to 2.5.0 then it will try to search for a dependency that no longer exists.

It might be possible with TGUI 0.7.5 and an unmodified SFML version if you just copy the SFML/cmake/Modules/FindSFML.cmake file to TGUI/cmake/Modules/FindSFML.cmake, but this was not tested.

https://github.com/SFML/SFML/pull/1379 changes a lot of code related to render textures and context switches. It might be interesting to see if it solves the problem as well or not.
You could try that PR and see if it solves the issue, but you would have to compile both SFML and TGUI yourself if you do (and you have to change the SFML version number to 2.5.0 in Config.hpp in order to compile TGUI).

Since it works on linux and windows 7 here, I don't see any more undefined behavior and you already mentioned that it works on windows 10, the only thing left that I can blame is the graphics driver. So I can't help you with getting it working on that pc.

Maybe you can try reproducing it with just SFML, i.e. create an sf::RenderTexture instead of a tgui::Canvas and delete it in ~cFormMore. If you can reduce the code to a simple program in a single file that doesn't use TGUI then you could ask on the SFML forum.

Although likely unrelated, move the following lines into your main function. Keeping them in global scope relies on undefined behavior.

Code (cpp) Select Expand

sf::RenderWindow mWindow;
tgui::Gui mGui;

Could you try replacing the following code in cForm with something similar like you did with the back button in cFormMore (i.e. don't remove the widgets and create the form inside the callback function, but do it later during the update function)?

Code (cpp) Select Expand

pButtonFormMore->connect("MousePressed", [=]()
{
pGui->removeAllWidgets();
formMore = new cFormMore(gui, guiTheme);
});

I can't really see anything wrong with the code that could cause it. Canvas is the only widget that uses an sf::RenderTexture, which is likely related to why the problem only occurs with this widget, but the actual issue could still be anywhere.

I'll try to build it here and run valgrind on it.

The important question that I would like an answer to is whether the crash happens after the main function ends or not. Try placing a breakpoint at the end of the main function to check if it passes that place before the crash. If the crash happens after the main function has ended then you are relying on undefined behavior since SFML objects (and thus also TGUI objects) are not guaranteed to work in global scope (due to the undefined order of construction and destruction of global objects).

If the crash happens before the end of the main function then this has to be investigated. Could you run your code in debug mode (while using the debug libraries of TGUI and SFML of course) and get a stack trace when it crashes? That should narrow down the problem, without a stacktrace I can only make guesses.

Is GAME_MANAGER or cForm a global object? Make sure that "GAME_MANAGER->getGui()->removeAllWidgets();" is called before the end of the main function.

I can't immediately come up with any other reason why the code could crash. If it isn't because the widget is still alive after the main function exits (which causes the internal sf::RenderTexture to still be alive), then you should try to find some minimal code that reproduces the problem.

No, this currently can't be done.
Widget don't really have a different look in the "disabled" state yet. This is on the todo list for 0.8-alpha, at least for the default white theme. By updating the theme I will have to test all widgets anyway, so I'll see if I can add such functionality. But this should not be expected soon, I still have to rework the focus state first and it isn't progressing very fast.

You should call gui.draw() before calling display() on the sfml window, otherwise you are rendering to the next frame which will overdrawn by the next window.clear() call.

The get function will return a pointer to the Widget base class because it can't know the type of the widget. So I also added a get function with a template parameter that will do the cast for you and return the correct type:

Code (cpp) Select Expand

tgui::Panel::Ptr pnl = gui.get<tgui::Panel>(pnlName);

If you ever have a Widget::Ptr that you have to upcast in another situation then you must use std::static_pointer_cast or std::dynamic_pointer_cast. I'm still looking for a good way to make that easier to do.

I see what you mean now (I didn't read your first post carefully enough). I'll add a setInvertedDirection function or something.

I perfectly understand that you want to stick to the stable version.
I've been working on 0.8-dev for more than 1.5 years already so what is stable to others feels old to me though
I have the same dilemma as I had with 0.7, I have many improvements that I want people to use but a lot of people won't (and probably shouldn't) use it because it isn't stable yet. I can either spend the next 2 years improving 0.8-dev until I consider it finished, but still see many people download the old version until that happens, or I can release 0.8 before it is really finished. I haven't really given it much thought yet, but considering I'm only one small rewrite away from an alpha version and knowing that 0.7-alpha was turned into 0.7.0 without a beta release in between, there might be a stable 0.8.0 release sooner than anyone might expect (still months away though).

You should try TGUI 0.8-dev, it uses floats for slider values (so negative should be possible) and there is a step size.
In the download on the website this "step" is still called "frequency", but I renamed it to "step" in the very latest version (downloadable from https://github.com/texus/TGUI) a few days ago.

You can communicate either through the forum, through email or via Gitter (either at https://gitter.im/texus/TGUI or in private chat). Skype is also possible (username texusius, but possible can't be found in search).

If you create the widget and send a pull request through github then I would gladly accept it.
It probably won't be very easy to write though, how to create a custom widget it also not documented so you will have to look at code from existing widgets. The ListBox class might be a good starting point to look at. Feel free to ask questions if parts of the code are unclear.
It would be best to use TGUI 0.8-dev to write the widget.

A TreeView widget would be nice to have but it is a lot of work and I don't have the time to implement it. So it probably won't be implemented anywhere soon unless you would implement it yourself.

The space between the arrows uses the border color. The space actually wasn't meant to be used like this. The problem was that the borders only defined an area around the arrows, it couldn't define what was inbetween (as you might want to make this slightly less or slightly more thick than the borders that are around the arrows). So I added a SpaceBetweenArrows option to set how thick the border should be between the arrows.

I don't see why it wouldn't be working. In the top image the colors you set (other than the border color) are ignored because there are textures, but the bottom image is clearly rendered using colors so it should work. Are you certain you called setBackgroundColor on the bottom spin button? Could you show the code that you use to create the SpinButton?

I tried the following and it worked:

Code (cpp) Select Expand

auto spinButton = tgui::SpinButton::create();
spinButton->getRenderer()->setBackgroundColor(sf::Color::Blue);
gui.add(spinButton);

Based on the note in the documentation, is there any chance the renderer was already using images before you called setBackgroundColor? In that case you have to remove the images as well:

Code (cpp) Select Expand

spinButton->getRenderer()->setArrowUpTexture({});
spinButton->getRenderer()->setArrowDownTexture({});

The setBackgroundColor function existed so that you didn't have to call both setBackgroundColorNormal and setBackgroundColorHover if you don't want the widget to have a separate color on hover.

Suggestions: It would be great if a step value exist. Also, a text shown with the current value in between buttons as optional would be great!

I'll implement the step value somewhere this week in 0.8-dev (as no more features are added to 0.7). Having a text in between is a nice idea, but not something that should be expected anywhere soon. I'll add it to my todo list though.

Although it would be nice to have, that seems like a lot of work. I don't have the time for it so it is unlikely that it will be added. Like some other widgets that are on the todo list, it may never be added unless someone else contributes the code for it.

A context menu could be implemented in your own code using a ListBox: https://tgui.eu/examples/0.7/pop-up-menu/

Could you provide some examples (some screenshots of existing programs) of how you want the menu and chatbox to look?
The only 2 widgets where there were plans to have both text and pictures were Button (already added in 0.8-dev as BitmapButton) and Tabs.

I removed the setVerticalScroll function because it will now be automatically determined based on the size of the slider. So you just have to call setSize with a larger height than width and the slider will become a vertical one.

Yeah, they aren't where you would expect them. I should add a list somewhere but I never find the time for it. They are a bit hidden in the documentation right now, you can't even find them all at one place, you have to manually look at the base class to find which signals are inherited.

Yes, "TextChanged"

Code (cpp) Select Expand

editBox->connect("TextChanged", [](sf::String text){});

The signals of the widgets are documented under the "detailed description" section in the docs: https://tgui.eu/documentation/v0.7/classtgui_1_1EditBox.html#details

I'm aware that it can cause a memory leak, but that is about the only thing that can go wrong. It won't just cause crashes.
I tend to capture shared pointers in lambdas out of convenience, but for a serious project it should indeed not be done. You won't find any shared pointers captured inside TGUI though, if there are then it would be considered a bug.

The issue was never with the constructor itself, just the lifetime of your object. It is important that you understand when objects will be destroyed and when you can still access things, because segmentation faults like you encountered are really hard to debug, especially when your program becomes larger. And since the issue had nothing to do with TGUI itself, I might not be able to help you next time. Debugging someone else's code is time consuming which is why I usually want a minimal code, as such code would immediately show whether the issue lies in TGUI or not.

1) The ChildWindow sends a "Closed" signal. You can just connect to it like this:

Code (cpp) Select Expand

childWindow->connect("closed", []{ std::cout << "Window closed" << std::endl; });

If you connect to the Closed event then you are responsible for removing the child window yourself. The above code will just print "Window closed" but the window will remain open. This was done to allow you to cancel a close (e.g. ask user to save before closing). If no signal is bound, the window is removed automatically, but if you connect to the Closes event then you need something like this:

Code (cpp) Select Expand

childWindow->connect("closed", [](tgui::ChildWindow::Ptr c){ /*some code*/;  c->destroy(); });

The "c->destroy();" is equivalent to

Code (cpp) Select Expand

if (c->getParent())
    c->getParent()->remove(c);

3 and 5) All widgets are shared pointers, which means they are destroyed when neither you nor the gui still has a pointer to it. If you close the child window and no signal is connected like shown above, the child window will be removed from its parent. If you don't keep a pointer to the child window or one of the widgets inside it then they will be destroyed at that moment.

2) If a window is closed, it gets removed from its parent by default as already mentioned above. If you still had a pointer to the child window in your own code then you simply have to add it again. If you didn't keep a pointer then you will have to recreate the child window completely.

An alternative could be to connect to the Close signal and just call "c->hide()", in which case it is still part of the gui and you just have to call show() on it later to "open" the window again.

4) You can use the setTitleButtons function for this:

Code (cpp) Select Expand

childWindow->setTitleButtons(tgui::ChildWindow::TitleButton::None);