Messages

Resizing the canvas will call "renderTexture.create(newSize)", while "clear", "draw" and "display" are just forwarded to the renderTexture.

The only thing that could be different with using SFML directly is that in order to render the canvas contents to the screen I just access "renderTexture.getTexture()" and render that texture. So maybe that texture is still flipped on Android (i.e. when using OpenGL ES instead of when using desktop OpenGL). I'll try to check that later.

Performance-wise, the slowdown is probably me copying the sf::Texture (that I get with the "renderTexture.getTexture()" call), in the display() function, to a different location so that it works together with the other rendering code.

Are you calling the "display()" function on the canvas when you are done drawing?
Not doing so can have this effect.

If that doesn't solve it then try rendering something directly in SFML with sf::RenderTexture (which canvas uses internally). If that also has the contents flipped then we know that the issue is with SFML.

I'm not sure what you mean with filestreams, but I've added an operator >> for std::istream now

What type would "in" and "out" be here?

For std::ostream and std::wostream, there already is a << operator. There currently isn't a >> operator.

I somehow missed your previous message before.

All you should need to do in your code is keep a flag that a message box is open, and not do anything in the main loop except for passing events to TGUI when the flag is set (until you get signal from the message box that it was closed).

I can try adding a function like "showModal" to the gui that takes away your control like "gui.mainLoop()", but I fear it might have problems that can't be solved. What happens when a user closes the SFML window while a modal message box is being shown? TGUI will read the close event, might return a "cancel" return value from showModal and your code will continue without knowing that the window was ever closed. This might not be so bad in SFML where you usually call "window.isOpen()" in your main loop, but this could prove problematic in code that relies on sf::Event::Closed being sent (which might e.g. happen in SDL backends as main loops there usually only end when SDL_EVENT_QUIT is received).
Resize events would also be discarded by TGUI, so your program would be unaware if the window size was changed while the message box was open.

The only case where showModal would work without issues is if you are already using "gui.mainLoop()". If you have your own main loop, which I imagine most non-trivial programs will have, then it simply can't work well if I take control of the main loop in TGUI while the message box is shown.

You can use the technique described in https://tgui.eu/examples/1.0/blocking-events-outside-child-window/, but with a MessageBox instead of a ChildWindow

This is indeed a bug. If the theme doesn't specify the DefaultTextColor property (which BabyBlue doesn't), then the text is rendered with a transparent color (even though DefaultTextColor property is internally initialized with a grey color as default).

This has now been fixed in the latest version (github commit).

Are you setting a custom theme?
The only difference between the default and normal text is that the default text can uses a different font, style and text color. So maybe the text color is transparent or the same color as the background color.

Can you try adding the following to check?

Code (cpp) Select Expand

editBox->getRenderer()->setDefaultTextColor(tgui::Color::Black);


That code should work, and it works here. So something else must be happening to cause this.
- Is the text being rendered when you type something into the edit box?
- Does the text show if you call setText?
- Are you certain there isn't another edit box placed on top of it?

In the 0.8 old way the const String was a last implicit parameter.

This way still exists. What changed is that the parameter now needs to have type tgui::String instead of sf::String.

Starting with TGUI 0.9, I made TGUI's code independent from SFML, so I have my own types for things like Vector2f and String now (partially also because I disliked how sf::String handled UTF-8, tgui::String will consider all char* or std::string as UTF-8 strings). There are constructors and conversion operations between the SFML and TGUI classes, so if inside your callback you really need an sf::String, because you e.g. need to pass the text to SFML, then you can create it with "sf::String sf_str(tgui_str);".

Do I need to pass editBox and then call getText() inside signal?

For information that isn't included in the implicit parameter (i.e. anything other than the text), this would be the solution.

You will need to manually update the maximum text width when the size changes, i.e. add something like the following at the end of the MyTguiSlider constructor:

Code (cpp) Select Expand

onSizeChange([this]{
    m_nameLabel->setMaximumTextWidth(m_slider->getSize().x - m_valueLabel->getSize().x - 10);
});

TGUI tries to search for both SFML 2 and SFML 3 as it won't know which you have installed. If it fails to find either, then it will display an error message about both of them.

When looking for SFML 2, if fails because it finds SFML 3.0.0
When looking for SFML 3, it fails with "Requested SFML configuration (Static) was not found"

Did you perhaps build shared SFML libraries and are trying to build static TGUI libraries? If you are trying to use a different shared/static config for SFML and TGUI then you need to define SFML_STATIC_LIBRARIES to either TRUE or FALSE to select how to link SFML.

I'm not convinced that there are many cases where it is useful.

In early TGUI versions text was auto-sizing almost everywhere: if the height of a button increased then so did the text size (which actually still happens if you were to set its text size to 0). This was however one of the main reasons why TGUI looked terribly inconsistent: every widget was using a slightly different text size. The change to a global consistent text size is not something that I would want to revert.

I do realize that it is currently hard to make the gui scalable without manually setting the text size every time, but I haven't found a good solution to this problem yet. I'm not convinced that text size should be scaled PER widget, which is why I don't like the idea of making the value a layout. I feel like there needs to be some way to scale the text size for the entire scene, such as e.g. passing a layout to gui.setTextSize(). That would be more limited, but enough for many cases.

One improvement I made while looking into DPI awareness was a way to scale the entire window as long as the aspect ratio stays the same. Although this information is placed inside the High-DPI tutorial, it is relevant for any case where you want to scale the entire gui (as long as the aspect ratio is kept): https://tgui.eu/tutorials/1.0/dpi-scaling/#scaling-tgui

At least with manually setting the text size in onSizeChange you have full control over what happens. It might be annoying if you have to set the text size widget by widget, but normally you would only need to set it in some parent widget to apply it everywhere (so you don't need much code).

You may want to update your TGUI version. The `<cstdint>` include was missing to compile with GCC 13 (https://github.com/texus/TGUI/pull/195)
This was fixed in the development version 2 months ago and the fix is part of the 1.0-RC release (https://tgui.eu/download/)

Nothing in TGUI or SFML is thread-safe.
Attempting to change text while another thread is rendering will lead to such crashes.

You shouldn't touch TGUI outside the main thread. You could, but then you have to assure that the main thread is blocked temporarily so that it doesn't access TGUI at the same time (which defeats the whole purpose or executing it in a thread).

That is not a valid theme file in any TGUI version.
Wherever you found that file probably also has a small tool to convert it into a valid TGUI theme.

You can find the official theme files from TGUI in the "themes" folder of the TGUI files that you downloaded.

The "Unhandled exception" means that a tgui::Exception is being thrown that you aren't catching. The exception might have a bit more information about what is going wrong.

You can change your code to something like this:

Code (cpp) Select Expand

int main()
{
    try
    {
        // Existing code here
        return 0;
    }
    catch (const tgui::Exception& e)
    {
        std::cerr << "TGUI exception: " << e.what() << std::endl;
        return 1;
    }
}
Then it would print the information about the exception to the console and exit the program instead of exiting the program with the unhandled exception error.

Hopefully the exception will tell you what the issue is. It's probably either going to be in opening the file or with parsing its contents.
- If the file can't be opened, make sure the path is correct. If a relative path doesn't work, try with an absolute path (but make sure to escape your "\" characters in the string or to use "/" instead). If an absolute path does work, then maybe your working directory isn't where you think it is.
- If the issue is with parsing the contents, then double check that you are using a theme file from the same TGUI version than you are using.

but the whole canvas is triggering events so even if I click on transparent area, the event is consumed. I tried to define a custom isMouseOnWidget to return false (because I dont care about events on this widget) but the event is still consumed.

It's normal that is doesn't check whether the part is transparent or not, but if you override the isMouseOnWidget to always return false then the events should pass to the widget behind it.

There is no way to let TGUI reference an existing SFML texture without copying it. The best alternative depends on where exactly the sf::Texture is coming from.

Is there a way, even tricky with custom code, to have a reference to sfml texture data ?

TGUI uses an sf::Texture internally, which indirectly can be accessed, but TGUI needs ownership of the sf::Texture. So you can write data directly into TGUI's internal sf::Texture (with e.g. the sf::Texture::update function), but this method isn't useful if the sf::Texture needs to be created in your own code (e.g. if it is created from an sf::RenderTexture).

I thought I could do a trick by drawing a sfml sprite in the draw function of my custom widget

Have you tried drawing the sprite to a tgui::CanvasSFML (https://tgui.eu/tutorials/1.0/canvas/)?

but the clipping doesn't work anymore obviously

Which clipping? Some clipping from your own code? Because a custom widget can define a clipping region during its draw code.

I want to have a widget that embed a huge sf::Texture, but it takes some time to copy it into a tgui::Texture and I dont like that.

How big an how long are you talking about?
The slowest part is probably the call to texture.copyToImage() so that TGUI gets the pixel data from the texture. In most cases I actually don't think you need the pixel data itself. So if copying one sf::Texture to another sf::Texture is fast enough for your task then maybe I can provide you with a hack that skips the copyToImage() call.

is it on purpose ?

No, it seems like that was just missing.
It has been added now (github commit)

Both overriding or using signals could work. I think of overriding as defining the behavior of the widget itself whereas signals are used to inform some external object that the event occurred, but you can use whichever looks easiest.

For the dragging I think it might be easier to work with overriding functions, as you can implement leftMouseButtonNoLongerDown() to know when the mouse was released anywhere on the screen (which you need to know after the mouse was previously pressed on top of the box).

I need to handle passing the event to the child widgets even if I inherited from a widget which normally has sub-widgets?

Yes, but this is easy to do. By overriding the leftMousePressed function you are replacing the existing implementation (which passes the events to the child widgets). You can simply add the following line inside your leftMousePressed implementation to execute the existing TGUI behavior (and then you have your own custom code before or after that line).

Code (cpp) Select Expand

Panel::leftMousePressed(pos);
One of the things that get executed by calling that line is calling processMousePressEvent at Container.cpp#L901 which does the actual work of finding the child widget below the mouse and passing the event along.

So I see "panel" is a "container" but not a "SubWidgetContainer", so I guess it also "does not forward"?

Any Container-based widget will forward events (unless you override its functions to do otherwise). The quote is about the difference between SubwidgetContainer and Widget, where Widget itself doesn't forward anything.

SubwidgetContainer is a special class, is uses a Container internally, but it acts like a regular widget (you don't get access to its children). It's purpose is hiding the Container implementation. If you don't care that the user of your custom widget can access it's internals then you are probably better off inheriting from a class that inherits from Container (like you are doing by inheriting from Panel, which falls in the "Approach 1: extending existing widget" category).

That was the alternative approach that I was also thinking about. I ignored that option earlier because I thought you wanted some quick way to convert an entire form.

The latest TGUI 1.0-dev build now has such a button next to the position and size values.

Implementing it might not be that hard, but I'm not sure how useful it is for any non-trivial forms.
There would be many situations where one or two widgets do need a fixed value, e.g. a sidebar panel that has a fixed width (while having a relative height and relative position).

An issue with just making everything relative is that the text size won't automatically scale, so the offset between a label and an edit box below it would change and they could start overlapping when going too small. The text in the edit box itself will also no longer look correct when you just start changing the height of the edit box based on the window height.

While I don't know what the best way is to make a responsible form, I don't really believe that just making all positions and sizes relative is a good method unless you only display a few buttons. Changing the view of the gui might be more useful in some cases where you need simple scaling. That being said, I'm not against adding some button to the gui builder to make everything relative in the currently opened form.

This issue was fixed last month (https://github.com/texus/TGUI/pull/195/files), but there haven't been any new manual tags since then. (I'm planning on releasing a v1.0-rc soon, but I can't say yet if it will happen in the next days or if it still takes a few weeks).

So for now you may have to rely on the "nightly_build" tag instead of "v1.0-beta"

You don't have to add getPosition() to addClippingLayer, it is already relative to the widget position (since it is relative to the position in the passed states). So the rect should probably be just "{{}, getSize()}".