Messages

I'm sorry I didn't reply earlier, but somehow the forum had disabled notifications for this particular topic (while other topics that were created before and after your questions still have notify active for each message by default). I have no idea how that happened. Just for testing, could you perhaps create a new empty topic (which I will delete once I see it). If I don't get a notification for that one either then it must be some setting related to your account while otherwise it was just a temporary issue.

How do you connect in 0.9? I used to be able to pass a function to listbox->connect("ItemPressed", cb) but I can no longer do this. listbox->onItemSelect.connect(cb); produces an error, as does passing (&cb).

"listBox->onItemSelect(cb)" or "listBox->onItemSelect.connect(cb)" should work. What error did you get, maybe you were still using e.g. an sf::String as parameter instead of tgui::String?

I see that setView no longer exists and setRelativeView presumably should be used, but setRelativeView doesn't take a sensible obiect that can be converted into the parameter it desires. I can no longer pass in a sf::View, or even the result of sf::View::getViewport() even though it claims it is looking for a FloatRect (error converting between sf::FloatRect and tgui::FloatRect).

Conversion from SFML types to TGUI types sometimes requires explicit casts (because of issues you could otherwise get with ambigous function calls), you would just need to type "tgui::FloatRect(sfmlRect)". Though in most cases you won't need to use SFML types when passing things to TGUI (although it is annoying when upgrading from 0.8 as you did already use SFML types everywhere, which is why I don't recommend upgrading an existing project unless you have to). TGUI now changes the view automatically with the window size, so the most common case to call setView has been removed. Whether you need setRelativeView or setAbsoluteView to set a custom view depends on what parameters you want to give. The documentation of these functions contain a code example (e.g. https://github.com/texus/TGUI/blob/49f818919363d04bd51c87799655d52dfb78e449/include/TGUI/GuiBase.hpp#L113-L117).

It seems that I need to pollute my code with now-necessary type names in order to get your tgui::String to convert into either sf::String or std::string accordingly. This is very ugly.

I'm not sure I understand what you mean. There are implicit conversions to std::string and sf::String, plus tgui::String has all functions that std::string has, so you shouldn't need to do any manual conversions.
There are only two places where you are forced to make changes to your code: in the parameter of a callback function and when casting an sf::String to a tgui::String (by using "tgui::String(sfStr)") (but casting from tgui::String to sf::String is implicit).

Could you backport the fixes to the widgets to 0.8 before proceeding any further with 0.9?

I'm willing to backport small changes, but it would be helpful if you mentioned which changes in particular you are interested in.

Documentation would be really helpful. Do you maybe have a younger brother or a cousin or a neighbour who could do it for you?

I agree, but there is nobody that can do it for me. I've mentioned it online many times in the past that I could use help with it, but nobody else contributes any documentation.
I am currently rewriting the installation tutorials, after which I will write some other useful tutorials. I want to get some minimal information available before I launch 0.9-beta.

This is the default SFML behavior (which I am no longer using in 0.9-dev exactly because most people probably don't want it).
You have to call gui.setView when you receive the Resized event, using the a view with rect (0, 0, newWindowWidth, newWindowHeight).

Code (cpp) Select Expand

gui.setView(sf::View(sf::FloatRect(0.f, 0.f, static_cast<float>(event.size.width), static_cast<float>(event.size.height))));

This is indeed undocumented.

passing ChatBox->getRenderer()->getScrollbar() into its setData(), modifying the background texture, and using the modified ScrollbarRenderer's getData() for ChatBox->getRenderer()->setScrollbar() has no effect.

That should have worked actually. Was the scrollbar already using textures? Because a known "issue" with the scrollbar is that it has to be given textures for track, thumb and arrows or it would use colors for everything. So if you only changed one texture while the others are still colors then it won't use the texture. That issue has recently been resolved in 0.9-dev though.

The WidgetRenderer constructor can be given the RenderData as parameter, then you can skip the setData call:

Code (cpp) Select Expand

tgui::ScrollbarRenderer renderer(ChatBox->getRenderer()->getScrollbar());
renderer.setTrackColor(tgui::Color::Red);
ChatBox->getRenderer()->setScrollbar(renderer.getData());

TGUI currently doesn't support a ToggleButton.
You can simulate it with a Label and a CheckBox (or RadioButton if you want to automatically untoggle the other buttons when one button is toggled). The checkbox is only used for the background image (it will have no text) and a Label is positioned on top of it to display the text.

The label needs to be centered and any mouse event should pass through it so that the checkbox acts on the mouse hover/clicks, so you will need the following two lines for the label:

Code (cpp) Select Expand

label->ignoreMouseEvents(true)
label->setPosition(bindPosition(checkBox) + (bindSize(checkBox) - bindSize(label)) / 2.0);

It isn't corrupted for me.

But you can ignore the template and just configure it the normal way. What exactly are you stuck on? Why would you decide to reinstall codeblocks? You say that all those libs work but not TGUI, then what doesn't work exactly?

Edit: forget the template. I never looked at it before, I just opened it for the first time and it doesn't contain what I expected. It's not very usable.

What exactly is the problem? What isn't working? Are you getting error messages?

Creating a video is too much work, plus I wouldn't be able to describe it any better than the screenshot and my post already do.

The steps to install a library are practically the same for any library. How did you install SFML? Just follow any SFML tutorial and instead of having "sfml-system", "sfml-window" and "sfml-graphics" components you just have a single component called "tgui". Everything else is identical.

In case it helps, someone created a codeblocks template for TGUI that will set the settings for you. But it might be just as difficult to use if you don't understand what you are doing.

heres a codeblocks template i made to save myself some time. it just links all the sfml libraries and tgui. it assumes you have your libraries in C:\CppLibraries\TGUI\lib and headers in C:\CppLibraries\TGUI\include. For the SFML libraries and headers, just replace TGUI with SFML, or you can just change the .cbp file to whatever your directories are. unzip it and chuck the folder in%APPDATA%\CodeBlocks\UserTemplates. it also includes the basic sfml example from the sfml website.
https://cdn.discordapp.com/attachments/287709846134849547/747676087051354122/SFML_TGUI_Template.rar

You can build your program with 2 settings: Debug or Release. In the screenshot (https://tgui.eu/resources/CodeBlocks-0.7/LinkerOptions.jpg) you will see those on the left side. If you click on the project name then it shows settings that are shared between the options, if you click on Release or Debug then the rest of the window you show settings specific to either Release or Debug. Usually you will always want to use Debug while developing and only build a Release version when you want to run the program on someone elses computer.

In CMake you set an option CMAKE_BUILD_TYPE. Was it set to Debug or Release? When your project is in Release mode (which you can change somewhere in a combo box at the top of codeblocks) then you must use libraries with Release as build type. Similarly in a project that uses Debug, you must use Debug libraries.

The tgui library that you build has a different name depending on what CMAKE_BUILD_TYPE and TGUI_SHARED_LIBS were set to in CMake.
- libtgui.a if CMAKE_BUILD_TYPE=Release and TGUI_SHARED_LIBS=TRUE
- libtgui-d.a if CMAKE_BUILD_TYPE=Debug and TGUI_SHARED_LIBS=TRUE
- libtgui-s.a if CMAKE_BUILD_TYPE=Release and TGUI_SHARED_LIBS=FALSE
- libtgui-s-d.a if CMAKE_BUILD_TYPE=Debug and TGUI_SHARED_LIBS=FALSE

The linker settings from the screenshot should already contain sfml-system, sfml-window and sfml-graphics. Adding TGUI is identical to what you should already have there. You just have to add tgui on top of that list (not at the bottom).

- If you build dynamic TGUI libraries (TGUI_SHARED_LIBS was set to TRUE in cmake) and will include tgui.dll next to your exe:
On the left side of the window, if Release is selected, under "Other linker options" you need to add "-ltgui" (without the quotes).
If Debug is selected, you need to add "-ltgui-d".

- If you build static TGUI libraries (TGUI_SHARED_LIBS was set to FALSE in cmake) and have SFML_STATIC defined in your project:
If Release is selected, you need to add "-ltgui-s".
If Debug is selected, you need to add "-ltgui-s-d".

If you followed the tuturial step by step then you will have only build one TGUI library (either Debug or Release), so only one configuration will work in CodeBlocks. If you want to be able to build both Debug and Release versions of your program then you just need to follow the "CMake" and "Building the library" steps from the tutorial a second time, but this time with CMAKE_BUILD_TYPE changed to the other option.

Since you use mingw 8.1 you will first have to compile TGUI with CMake (and SFML as well). Have a look at https://tgui.eu/tutorials/0.8/codeblocks/
Feel free to ask if you get stuck at some step.

I have patched the issue. There was a typo that caused the Unfocused handler to be connected to Focused callbacks instead of Unfocused callbacks.

There isn't a new nuget package yet, but you can download the up-to-date nightly build by clicking the following download link: TGUI.Net-0.8-dev-64bit.zip

The connect function has been removed in TGUI 0.9-dev.
There are no tutorials for this version yet, the only indication that the connection function was removed is in the changelog:

- Rewrote signal system again, b->connect("Pressed",...) is now b->onPress(...)

So you have to use those onXxx members now.

If you are in a situation where you only have the string that you want to connect (e.g. the "pressed" string was read from a text file) and you need to connect dynamically and can't use those onXxx members then you can use widget->getSignal(signalName).connect(...).

So the problem is that only the selected panel is part of the container, right?
I think all panels should be added to the container, you should just use setVisible to show/hide to right one instead of removing and adding from the container.

I think it would be good to provide method for changing height of Tabs in some form

I agree, there should be some way to customize the height. A setTabsHeight function could be added.

In code above I just use getTabs function, but I removed it in PR because I don't see any sense to provide full access to private member in library. Or am I wrong and such function is OK?

I'm ok with having some internal classes exposed. Ideally, all functionality should be in the outer class so that nobody would ever need to access the internal classes directly, but in cases like this, having access to the Tabs class would allow people to do some extra things that wouldn't be possible with only the functions in TabContainer. That being said, such a function should only exist to provide internal access for use cases that someone else might think about in the future, not for existing use cases. Being able to do something via getTabs() is not an excuse to not provide the functionality in TabContainer. So a function to set the height of the tabs should still be added, even if getTabs() is added as well.

In the documentation of the getTabs function you say that it returns the internal Tabs object. The word "internal" should definitely appear in the description to indicate that you are typically not supposed to use the function. I used to mark such functions as "@internal" as well, but that removes them from the documentation by default, so now I try to only do that if I really don't expect a user to ever call the function.

it's needed for case if user forbid selection changing in onSelectionChanging handler

I didn't look at the code closely enough to realize that you added the ability to abort the change. I should probably do something similar for closing ChildWindow.

Some other minor remarks:
- There are still some functions starting with capital letters (Select and Count).
- Documentation should only start with "//!<" if it is placed next to the code. If above the code, it should just be "///".
- Count() should probably be renamed to getPanelCount() for consistency with other widgets.

About the coding style, I usually don't write braces around bodies in if statements when they only contain a single line of code. For example

Code Select Expand

if (idx == 0)
{
    Select(m_panels.size() - 1);
}
else
{
    Select(idx - 1);
}could be written more compactly as

Code Select Expand

if (idx == 0)
    Select(m_panels.size() - 1);
else
    Select(idx - 1);

I don't care enough about it to remove them when cleaning up the code (I kept them in SpinControl as well), but I do see them as superfluous (unless they are added to increase readability such as with nested for loops or when the body of the if statement is split over multiple lines).

I would call it TabContainer.
- The name PanelHolder doesn't indicate that there are tabs.
- Notebook widget is hopeless to search for due to Jupyter Notebook.
- I didn't have any better ideas myself, TabbedPanel doesn't sound good.
Googling for TabContainer does provide some results on what it is, so even if people don't immediately know what it does from the name they will easily be able to find a description.

The code mostly looks fine. A few remarks:
- Why double the height of the tab in the constructor?
- addPanelAt should be called insertPanel for consistency with other widgets
- Is "m_tabs->select(m_index);" in "m_tabs->onTabSelect" in tgPanelHolder constructor needed? Wouldn't it already be selected before this callback function is even called (and changed a second time in the Select function)?
- Perhaps you should only call "m_tabs->select(index);" in the Select function when the index in the tab is different (i.e. when the user called select himself). Right now you have something that looks like a recursion: Select calls m_tabs->select which triggers onTabSelect in which you call Select again. This works because the Tabs widget doesn't send another callback when the index didn't change, but it might be better to not rely on such internal behavior of Tabs (even if the behavior is never going to change).
- The documentation (comment above class) should probably mention that if you want just the tabs without the panels then the Tabs widget can be used. Similarly, the documentation for the existing Tabs widget should get an extra note that it doesn't contain any panels but if people want a panel directly below their tabs then they can use the TabContainer widget.

Not really, I don't even have a mac
You can probably just delete the .framework file (if you can find the folder where it gets installed to). Although I don't think the framework would be causing conflicts.

Have a look at https://stackoverflow.com/a/61536481 for a random recent guide on installing sfml. Maybe you still have some wrong directories in the library path?

Is there a libsfml-window.2.5.dylib file in /usr/local/opt/sfml/lib/?
You could try reinstalling sfml with homebrew, maybe something broke when uninstalling the other version?

You should remove the one you installed yourself. They are likely identical versions and it won't matter which one is removed, but the homebrew TGUI package is build with the homebrew SFML version so you can be certain that those are compatible.

It seems like you have 2 SFML versions installed on your computer (probably one installed manually and another installed via homebrew, possibly while installing tgui). One is installed in /usr/local/lib/ and the other is installed in /usr/local/opt/sfml/. The TGUI homebrew package was build with one of those (the one from homebrew) and will require exactly that one SFML version in order to work, so you have to uninstall the other one.

I've implemented saving and loading. Some fixes unrelated to SpinControl were needed to make it work.
The mouse cursor change has also been added by now.

TGUI 0.9-dev will now change the mouse cursor when hovering over the borders of a child window (if setResizable(true) was called).
The code was a lot more complicated that I originally thought so there is no chance at all that this would be backported to 0.8.

More information about the final design can be found in the announcement I made in Discord:

TGUI 0.9-dev now supports changing the mouse cursor.
There are 3 ways the mouse cursors are used:

1) Resize cursors will automatically be shown when hovering over the borders of a resizable child window. The default invisible border width has also been increased from 5 to 10 pixels. Those changes make resizing a child window a lot easier.

2) A setMouseCursor function has been added to the Widget class. The requested mouse cursor will be shown when the mouse hovers over the widget. The following line would cause the I-beam cursor to be visible when hovering over an edit box:
editBox->setMouseCursor(tgui::Cursor::Type::Text);

3) You can set a mouse cursor that will be used anywhere on the window and which overrides the cursor from the previous two methods. To do this, call the setOverrideMouseCursor on the Gui object. Call the restoreOverrideMouseCursor() function later to let the gui change the cursor automatically again based on the widget below the mouse.

Styling the cursors:
System cursors are used by default. Bitmaps are also supported by using the static tgui::Cursor::setStyle(Type type, const std::uint8_t* pixels, Vector2u size, Vector2u hotspot) method.

Changes to building TGUI:
- Minimum SFML version was increased from 2.3.2 to 2.5.0
- TGUI will now links to X11 on Linux to work around a limitation in SFML

The code has been merged. Thanks again for contributing this.

I noticed that there is still a warning left, but I will fix this myself. Once I'm done with what I'm working on (ability to change mouse cursors plus some code reorganization), I'm going to have a detailed look at the code you added and make some nitpick changes anyway.

Does it really matter that if the user typed "123text", we keep the "123" instead of resetting the value? I don't think anyone is even going to notice the behavior (because you typically do type actual digits in it). And I would kind of consider it a feature that it keeps the value I typed if I accidentally hit another button together with the enter key .
Maybe the edit box should have Validator::Float set, that way you can't even type text or have multiple commas.

The compile error is coming from line 45 because you have a generic lambda. GCC 5 doesn't seem to like it that you call a member function from inside a generic lambda. You should change "auto" to "float" there. I personally never use auto for simple integers and floats, usually it doesn't matter but in this particular case you can't use auto (at least not when keeping the older compilers supported).
There are also a few warnings about you reusing the "value" variable name multiple times in the same function (line 45 and 69 reuse the name declared at line 33).

It's probably not going to be finished this weekend. The implementation is a bit more complicated than expected (e.g. the mouse cursor is tied to a window and therefore to a specific Gui object). Because of this I decided to add the cursor code together with a larger change, so it will take a bit longer.

Thanks a lot. I'm sure several people will find this class useful.

The only think that I miss in the class is the setSize function. If setSize is called on the SpinCtrl, the spin button should probably keep its ratio (so if height is doubled then width is doubled too) and the edit box would take up all the remaining width.

I'm not a big fan of having a createIntegerSpinCtrl function, I would prefer that all widgets would be created via the 'create' function, but I don't see many alternatives either. Maybe instead of choosing Int vs Float, there should be an amount of digits behind the comma? If set to 0, only ints get accepted, if set to 2 then "x", "x.a" or "x.ab" would be accepted but "x.abc" would be rounded. The default could be -1 which allows any float input.
Maybe the TextChanged event could also be replaced by ReturnOrUnfocused, so that you can still e.g. copy "x.abc" into the edit field and it would only be rounded and accepted when pressing enter or unfocusing the edit box?
Ultimately I'll leave this decision up to you, it's just some idea to think about. I would merge the class no matter how the int vs float is solved.

Instead of using std::stof and exceptions, I think String::toFloat should be used. Whether we should depend on the locale to parse numbers is arguable, but for now it would probably be best to rely on the code always behaving the same on every pc. I recently discovered that std::stof does depend on the locale and may turn "1.5" into "1" for some people, which is why I stopped using std::stof in the String class.

Finally some nitpicks. Maybe you would have already made some of these changes when cleaning up the code, but here are a couple of minor things that don't correspond to the rest of TGUI code:
- You can use SignalFloat instead of SignalTyped<float>
- SetValue shouldn't have capital S
- Lowercase 'f' instead of 'F' is used in TGUI behind floating point numbers
- If a value isn't going to be changed, it can be a 'const' variable (e.g. curValue)

I'm a little afraid of retro compatibility between 0.8 and 0.9,  do you think we'll have to re-write a lot or is it can be used as is?

There have been quite some changes. A large part of the API remained the same, but e.g. connecting callbacks are different and some parameter types were changed. Updating should be possible within a couple hours, but it might be annoying work. If you are loading all your widgets from a text file then I can't recommend updating as there is no way to import 0.8 files in 0.9 (although if you don't mind boring work they can easily be updated manually in less than a day, I had to update the screens in the gui builder itself by hand too).

I'm impressed on how you handle feedbacks

I definitely try to work on stuff that people suggest, but you also need to have some luck to get a feature implemented. Things get asked for often without them being implemented (usually due to lack of time). This wasn't the first time (nor the second time...) this functionality was requested, I even knew I needed it when I originally added support to resize the child windows. So it was something that I have known to be a limitation for quite some time and I had already given it a lot of thought (not necessarily in exact implementation, but about what challenges there would be and which ways I shouldn't implement it). That combined with the fact that I was almost finished with a large change for 0.9 and was looking for the next thing to do caused this to appear high on the todo list. I just finished what I was working on yesterday (reorganising some code, making widgets even less dependent on SFML), so I'm actually planning on looking into the cursor thing this weekend.