Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: [1] 2 3 ... 106
Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 20:05:12 »
Could it be that C:/Strawberry/c/include/freetype2 is giving a conflict with the freetype that comes with SFML?

Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 20:01:39 »
I don't see anything wrong with those files, it says that it has freetype at T:/libraries/C++/SFML-2.5.1/extlibs/libs-msvc-universal/x86/freetype.lib

Did you download the SFML version from github?
You are setting TGUI_SHARED_LIBS to FALSE, right?
Could you send the CMakeCache.txt file from your TGUI build?
Could you send your entire SFML folder?

I'm not sure when I'll find enough time to look into this in detail, but if you send me those files then I'll try to find some explanation when I find the time.

By placing the old code back in TGUI's cmake you are changing the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH variables and the issue is only solved as a side-effect of this (those lines existed in the cmake script for building the gui builder and tests, not for finding sfml). So although it works, it isn't really the solution (it only works by accident that way).

Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 18:48:34 »
Could you send the SFML*.cmake files to me that you have inside your build folder?

Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 14:10:28 »
Then were did the SFML folder come from?
SFML doesn't has a SFMLConfig.cmake in the root by default. If you e.g. download it from the SFML website then the file will be in lib/cmake/SFML.
Did you build SFML yourself with CMake? If so, did you create a build directory?
The only case that I can think of where the file would be located there is when you build SFML with CMake and set the build directory to the same as the source directory, but even then it should be able to find freetype.

Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 13:41:57 »
Did you manually copy the SFMLConfig.cmake to a different location, because it seems like SFMLConfig.cmake can't find FreeType? The SFMLConfig.cmake hardcodes relative paths, so you are supposed to keep the SFML folder structure.

The SFML_ROOT method hasn't been recommended for quite some time already (because SFML changed the way you are supposed to find it with CMake), and I don't recommend adding back the code that uses it.

It might work when you put the hardcoded paths back into TGUI's CMake file, but the whole idea of using SFMLConfig.cmake (compared to the old FindSFML.cmake) was that I wouldn't have to hardcode these extlib paths anymore.

Help requests / Re: Menu item clicks
« on: 14 September 2020, 17:03:17 »
The connectMenuItem function is still the correct way to do this (and it just calls onMenuItemClick internally). Although it is a bit weird that all other connects are handled by onXxx, it has always been a bit of a weird function (since every other signal used the normal "connect" function while here you needed "connectMenuItem"). I don't immediately see a better way to do it, so connectMenuItem is likely going to remain unchanged.

Help requests / Re: How do you connect in 0.9?
« on: 14 September 2020, 16:56:25 »
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.

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.

Help requests / Re: Screen sizing
« on: 11 September 2020, 17:50:04 »
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).
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:
tgui::ScrollbarRenderer renderer(ChatBox->getRenderer()->getScrollbar());

Help requests / Re: Button Down
« on: 28 August 2020, 19:28:27 »
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:
label->setPosition(bindPosition(checkBox) + (bindSize(checkBox) - bindSize(label)) / 2.0);

Installation help / Re: Help me Codeblock
« on: 27 August 2020, 08:20:25 »
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.

Installation help / Re: Help me Codeblock
« on: 26 August 2020, 22:14:22 »
What exactly is the problem? What isn't working? Are you getting error messages?

Installation help / Re: Help me Codeblock
« on: 26 August 2020, 08:24:04 »
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.

Installation help / Re: Help me Codeblock
« on: 25 August 2020, 08:37:34 »
You can build your program with 2 settings: Debug or Release. In the screenshot ( 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-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.

Installation help / Re: Help me Codeblock
« on: 21 August 2020, 08:15:34 »
Since you use mingw 8.1 you will first have to compile TGUI with CMake (and SFML as well). Have a look at
Feel free to ask if you get stuck at some step.

Pages: [1] 2 3 ... 106