Messages

Only freetype.lib is included with SFML, gdi32.lib, winmm.lib and opengl.lib (not openal.lib) are part of Windows. You only have to add those to the linker settings, you don't have to copy them anywhere.

Are you using CMake for your project? Because I was assuming that you were using Visual Studio directly. The procedure to link SFML and TGUI is different in CMake. If you are using cmake for your project, can you show how you are searching and linking to SFML and TGUI?

Since you are using precompiled libraries for SFML, is there a specific reason why you aren't using precompiled libraries for TGUI?

Also, what is difference between the "gui-builder.exe (install)" and "gui-builder.exe" ?

Where do you see those? I'm not sure what you are referring too.

Did you build TGUI or SFML yourself or did you download them from the website?
I think this error might be possible when using a different SFML dll than was used to build TGUI with.

Did you build the debug TGUI libs to a different build folder than where you build the release TGUI libs?

If you link statically then there are 2 things to do that would give you many linker errors if you didn't (most people forget the second one):
- Define SFML_STATIC
- Add opengl32.lib, freetype.lib, winmm.lib and gdi32.lib to the linker libraries (where you added SFML .lib files). Those are SFML dependencies which you need to link to when linking statically.

I agree that it would be very useful, but it is more challenging to implement than you might think at first sight.

One positive thing about implementing ctrl+Z is that not everything has to be supported initially: an early implementation might only undo some things while some other actions and edge cases can be implemented later. A partial implementation is not ideal, but it is still better than not being able to undo at all.

I currently have some other tasks that I want to get done first, so I won't be attempting to implement this myself soon. Help is always welcome, but if you or someone else doesn't contribute it then eventually I will add this myself.

Negative positions should work fine. What error do you get?

You are allowed to use multiple Gui objects for this, but I don't recommend it.

If part of the gui should be stationary then put all those widgets in a Group widget and keep the group at a fixed location. The stuff that needs a different "view", which needs to move around, is put into a different group. You simply change the position of the second group whenever you need to move it around. The only widgets that are added directly to the gui would be the two groups, all other widgets would be added to one of the two groups.

It should be exactly the same as with the lambda, so like this:

Code (cpp) Select Expand

void buttonPressedCallback2(int customValue, tgui::String buttonText);
button4->onPress(&buttonPressedCallback2, 5);

Yeah, it's only with modern c++ that Intellisense had issues, it does work fine for older projects. It feels like it is using an older compiler version under the hood.

The code doesn't has to be as modern as you might think to cause issues though. One example that Intellisense couldn't handle until recently is a constructor declaration like "constexpr Vector2() = default", which is perfectly valid even in c++11. I used "constexpr Vector2() {}" for a long time in my code just to work around that issue.

TGUI actually still uses c++14 by default, but it may activate features from newer c++ versions when available (i.e. when you select a higher standard version in Visual Studio).

If it compiles then there is nothing wrong with the code.
Visual Studio uses IntelliSense to detect issues without compiling, but IntelliSense has plenty of bugs itself, which don't even get fixes if you don't have the latest VS version.

At the bottom, above your errors, you have a combo box with "Build + IntelliSense". I think you can change this to just "Build" to only see the real compiler errors.

You don't actually need to do it when creating it, you can do it at any time.
If the callback gets called multiple times then you are probably calling onClick on the same button multiple times though (e.g. if the update() function is called more than once).
You can run button->onClick.disconnectAll() before connecting the callback function to remove all previously connected callbacks.

No, such a widget doesn't exist unfortunately.

For a RichTextLabel I have some WIP code lying around, but there the text is static. A RichTextArea to be used as a text editor is far more complex and I've never started working on it. So this is not something to be expected anytime soon either.

The viewport defines which area of the window is drawn to (you probably don't want to change this) while the view defines what is drawn to window (or at least the part of the window specified by the viewport).

Both viewport and view can either be given as absolute or relative.
When absolute, they are specified as a certain amount of pixels.
If the viewport is relative, the parameters are a ratio to the window size (e.g. a relative viewport width of 0.6 corresponds to 60% of the window width).
If the view is relative, the parameters are a ratio to the viewport size, which by default equal the window size (e.g. a relative view height of 1.2 equals 120% of the viewport height).

If you just want to zoom then you could use "setRelativeView({0, 0, 0.5f, 0.5f})" to zoom in 2x.
If your window is 800x600, then it renders everything within the (0, 0, 0.5 * 800, 0.5 * 600) coordinates to the window, thus magnifying the gui.

If cameraZoom is greater than 1, then "setRelativeView({0, 0, cameraZoom, cameraZoom)" will zoom out.
Note that you need setRelativeView and not setRelativeViewport!

The gui ignores the view set in the window, it instead uses its own view.
You can use gui.setAbsoluteView to pass the (left, top, width, height) of the region to show in your window.

mainLoop mostly exists to simplify my example codes, you would almost always need to use your own main loop in a serious project.

You don't have to copy TGUI's implementation, it is more difficult than what is needed in your code. You only need what is described at the bottom of
https://tgui.eu/tutorials/0.10/backend-sfml-graphics/#main-loop

but they are counted in different ways - here the TGUI API could be a bit more consistent

That's a general issue in TGUI, the code and design has changed a few times over the many years of development, and there is a lack of direction.

There has been an attempt at the beginning of 0.10-dev to make all rendering and layout use reusable building blocks. The prototype can still be found in the Component.hpp file and is only used by the Button widget. The idea was that backgrounds and text (or each tab) would be a component, and widgets would also be a component. This would result in the consistency you are talking about: child widgets or individual tabs would be treated in a similar way.

The component design had its own issues and the idea has been put on hold for now. Maybe for TGUI 2.0 I can revisit this topic and figure out a better design.

you would then have to consistently tear apart enum TabAlign - and that makes the API more complicated again. Any idea to solve that?

TabAlign can be moved inside TabContainer, and it would only need a Top and Bottom member as whether or not it uses FixedWidth would in my vision be detemined by some kind of setFixedTabWidth function.
Since there would only be 2 members, an alternative would be to not have an enum at all and just have a setTabBelowPanel(bool) function.
The bool function is how I would have done it, but I have a habit of choosing the most straightforward method to solve issues and not necessarily the best designed one (so I'm not saying you have to do it like that). Keeping the TabAlign enum has the advantage that it could be extended in the future if it becomes possible to have vertical tabs and align tabs on the left or right side of the panel, but this is unlikely to happen any time soon (if ever) so the design can always be changed later if it would be implemented.

Keep things simple and separated in order to minimize maintenance effort (in contrast to other tools that try to maximize programmer's convenience).

I think in many cases you have find a bit of a compromise between maintainability and programmer convenience.

Keeping things separated might also help to user to more quickly find what they are looking for (although good documentation can help a lot with that too). And I generally do like to keep things as simple as possible.

Isolated/separate code can usually be changed without consequences, but code that is used across widgets usually has an entire history and limitations surrounding it that you can't really be aware of. The layout code for example is newer than the Tabs widget, and it was only created to provide an alternative to fixed positions and sizes (because in TGUI 0.6 the position and size of a position was specified in pixels and couldn't be specified in percentages or relative to other widgets). While it is used from some places inside TGUI, it wasn't designed for that and the entire layout system actually needs a big redesign (also no planned until TGUI 2.0). The more complexity that gets added to the layout classes, the harder it will become to redesign it.

If I'm right about that - shouldn't that be pointed out somewhere?

I find it difficult to really formulate rules about how things should be done as there is no clear philosophy, I generally just try to keep things simple.

But this is similar to another issue: there is no goal on how to go forward. Should the API be as easy as possible or should it allow as much customization as possible? While I aim for both, those goals often collide. While I lean more towards simplicity, I don't really have any philosophy about which direction TGUI should grow in, so I also can't provide rules to other on what to do.

Maybe you've already noticed: I'm a big fan of good documentation - especially for a beginner in TGUI like me it would be very helpful.

Documentation is definitely lacking in TGUI, but I'm not that good at writing documentation and tutorials

TGUI 0.10-dev is going to be rebranded as TGUI 1.0-dev soon, and I'm planning on allocating some more time to document stuff afterwards. The current TGUI design still has many limitations, but at some point I just have to stick with something and work within the limitations that exist instead of keep rewriting things.

You can't push directly to texus/TGUI (which is what I assume you get "access denied" for), you have to create a fork (which I think you already did: https://github.com/SteffenPloetz/TGUI).

In your fork you should be able to commit changes and push them. If that works then you should see the changes at https://github.com/SteffenPloetz/TGUI

On your fork on github, press the "Pull Request" tab on top (which takes you to https://github.com/SteffenPloetz/TGUI/pulls), where you can press the "New pull request" button to send the changes to the main TGUI project. After you filled in your description and send the request, I would get notified about it and the pull request will appear publicly on https://github.com/texus/TGUI/pulls

Unfortunately I think your changes are a bit too invasive to the code to be merged as-is: I don't like seeing changed to the Layout or global scope (tgui::TabAlign) for something specific to one widget. While bindNumberOfChildren might have other use cases, I feel like such addition needs to be discussed first and not merged together with a small addition elsewhere.

The setTabAlign function combines 2 unrelated properties: location of the tabs and whether they use the full width or not. While you probably needed to change both for your use case, I think it would be more useful to others if they are separate. Both properties are useful, but I think there are going to be people who just want to have fixed-sized tabs and they won't expect the function they need to be called "setTabAlign".

If it helps reduce the code then I'm fine with combining multiple properties like in TabAlign, but you need a setTabFixedSize function anyway, so I think you might as well use that function to determine whether the tabs have a fixed size (e.g. the default value is 0 in which case tabs have the old behavior, while calling setTabFixedSize will choose a fixed tab width).

First of all, thank you for being willing to help and contribute code.

You could send a Pull Request on github with the changes you made. That way I can see what you changed exactly, provide feedback on it if something still needs to be adjusted and eventually merge the change into TGUI for everyone.

TabContainer shouldn't become too complicated as the user can always create the Panel and Tabs widgets themselves if they need more control, but the changes you describe seem like helpful additions so I'd happily accept those.

How did you make the tabs fixed width exactly? By specifying the total width of the 3 tabs, or by adding some function that specifies the width of a single tab and then have the Tabs widget grow when adding another tab?
If implemented properly, the latter might be useful for the Tabs widget itself as well (and not just TabContainer).

I guess I should have the CONTRIBUTING file explicitly link to the Issues and Pull Requests on github to make it a bit clearer.

I just tried replacing my project file with yours and correcting the paths to TGUI and SFML and it still worked fine here. (I only had to remove some extra libs you were linking to in release mode, but those can't be the issue because they weren't linked to in debug mode)

Those are the binaries I generated, does this run on your system?
https://www.dropbox.com/s/po1arrgrto0pdsy/testTGUI_Opengl_sfml_VS2015_x64-bin.zip?dl=1

Try copying all dlls from those binaries next to what you are generating and see if that changes anything.

The only difference between your system and mine that I can think of is the Visual Studio version. I'm using VS2022 with the v140 compiler, while I assume you are still using Visual Studio 2015 directly. While it shouldn't make a difference, it is possible that this is part of the problem. Is there a reason why you still need to use VS2015?

Can you share your Visual Studio project that is giving you this error?

Here is an x64 version:
https://www.dropbox.com/s/71aqct5jye7ctym/TGUI-0.10-dev-x64-VS2015-SFML2.5.1-FreeType2.10.4.zip?dl=1

Are you linking dynamically to freetype? Do you also get this error when the freetype dll is present next to the exe?

I have build TGUI with the same libraries, can you check if you also get the problem when replacing your TGUI files with the ones from https://www.dropbox.com/s/mz8okpedfj1hlo2/TGUI-0.10-dev-VS2015-SFML2.5.1-FreeType2.10.4.zip?dl=1 ?

Did you change the font in the renderer of the button? If you change the font in the theme or via getSharedRenderer() then it is applied on any button, even those from other states.

If a font is set in the renderer, then the widget will use that one.
If the renderer has no font, then it selects the font from the parent widget (if it has one).
If neither font exist, then the default font is used.

Setting the font of the renderer overwrites the font on all widgets connected to that renderer immediately.
Calling Gui::setFont or setting the renderer font of a container will cause all child widgets to inherit the font and change to the new font unless their renderer specified a different font.
Calling Font::setDefaultFont font only affects new widgets, not existing ones.

(I really need to do something about this forum, since I updated the forum software I've had a lot of issues with notifications. I didn't get any notice about this topic. You might find quicker help on Discord)

The ugly text rendering will need to be investigated further. It looks like bad anti-aliasing.
Edit: maybe the framebuffer needs a multisample attachment, such as described in the "Off-screen MSAA" section on https://learnopengl.com/Advanced-OpenGL/Anti-Aliasing

Try disabling GL_CULL_FACE before rendering TGUI, having that enabled also seems to remove the text. I see your code enabling it right after the shadow manager, so maybe that is the problem instead of the shadow manager itself (which I haven't tested here yet).

The error seems to be the GL_DEPTH_TEST capability.

I don't really get why it works without the framebuffer and not with one, but the reason it only renders the button background and not the text is because they both have the same depth and OpenGL only draws the first one. This is why rendering a Label still works, it has nothing behind it.

I will fix this in TGUI later, for now just call the gui.draw() function like this:

Code (cpp) Select Expand

glDisable(GL_DEPTH_TEST);
gui.draw();
glEnable(GL_DEPTH_TEST);
Edit: The latest TGUI 0.10-dev release now handles GL_DEPTH_TEST and you no longer have to disable it yourself with that version.

Thanks. I have the code working and can reproduce the problem now.
I will try to find the issue tomorrow.

This project uses my own engine. If you have time and will to build it, I can send you a github page.

If you send me a link to the github page then I will build it (or copy the relevant code). I need to know exactly what the Framebuffer class is doing in order to debug this, so I would need to see the source code.