Messages

I don't have much time to answer right now, so I'll answer with what I remember, you might have to experiment a bit with it yourself to fully see how well it works.

SVGs are only rasterized when rendering. The result may be cached, but when you resize a widget, the cache will be cleared. The code to draw SVGs hasn't been tested much, and it's not as well optimized, but it should normally work.

Placing all graphics in a single image is purely an optimization, so that OpenGL will have to switch the texture less often when rendering. I don't think it's even compatible with SVGs, so you probably have to use separate image files anyway.

I don't know much about the vcpkg package (someone else maintains it), I do however know that the vcpkg package should contain an optional "tool" feature that is linked to the TGUI_BUILD_GUI_BUILDER option (https://github.com/microsoft/vcpkg/blob/master/ports/tgui/portfile.cmake#L39).
So if you know or look up how to enable package features in vcpkg then you might be able to get the Gui Builder by installing that "tool" feature in the "tgui" package.

No worries, you aren't wasting my time, I'm happy to help.
The nightly builds should also be stable (and I even tested it here with the latest version), so I don't see why it wouldn't work.

It's a good thing that you managed to get it to work now though, because I wouldn't actually have time in the next week to dig further into the issue. So unless someone else runs into the same issue or you get it again in the future when upgrading, I'm just going to pretend that this was a one-off temporary issue that needs no further investigation.

That doesn't make much sense.

Can you verify that a program with just the following code still crashes?

Code (cpp) Select Expand

#define NOGDI
#define NOUSER
#include <raylib.h>
#include <TGUI/TGUI.hpp>
#include <TGUI/Backend/raylib.hpp>

void run_application()
{
    tgui::Gui gui;

    auto menu = tgui::MenuBar::create();
    menu->addMenu("File");
    menu->addMenuItem("New Project");
    menu->connectMenuItem({ "File", "New Project" }, [] {
        std::cout << "Let me print! \n";
        });
    gui.add(menu, "menu1");

    gui.mainLoop();
}

int main()
{
    SetTraceLogLevel(LOG_WARNING);

    InitWindow(800, 600, "TGUI example (RAYLIB)");
    SetTargetFPS(30);

    run_application();

    CloseWindow();
}
- Are you linking statically or dynamically to raylib?
- What TGUI and raylib version are you using?
- Are you using precompiled builds or did you build TGUI and/or raylib yourself?

Is the access violation giving you an address where it is reading from, and is that address near 0? If that would be the case, is there a chance that the menu bar on which you are calling connectMenuItem hasn't been initialized yet?

If that isn't the problem then could you perhaps share some minimal code that reproduces the issue?

Did you add TGUI_STATIC to your preprocessor definitions?
It has to be defined when linking statically, otherwise the linker will search for these symbols in loaded DLL files instead of in the static library.

I created a minimal example with esp-idf that had the following in the "main" directory.
The test.c file was practically empty and the TGUI sources where copied into main/TGUI.

Code (cmake) Select Expand

# "Enable C++ exceptions" and "Enable C++ run-time type info (RTTI)" must be checked in menuconfig
idf_component_register(SRCS test.cpp
                       INCLUDE_DIRS ".")

set(TGUI_BACKEND "Custom")
set(CMAKE_SYSTEM_NAME "Linux")
set(BUILD_SHARED_LIBS OFF)
set(TGUI_INSTALL OFF)
add_subdirectory(TGUI)

target_link_libraries(${COMPONENT_LIB} PUBLIC TGUI::TGUI)

One change that had to be made in the TGUI sources was to remove the "target_link_libraries(tgui PRIVATE ${CMAKE_DL_LIBS})" line in TGUI/src/CMakeLists.txt.
I imagine that this could cause linking issues later with the code in FileDialogIconLoaderLinux.cpp, so maybe that code might need to be removed later as well.

The "idf.py build" command succeeds like this, and it seems to have compiled TGUI in the process (because it threw a lot of errors initially before I enabled exceptions and RTTI). This is as far as I'll be able to build myself, the next steps will be up to you. But feel free to ask if you encounter specific errors about the TGUI code later.

The TGUI_BACKEND will still have to be changed to use SDL as well once you can get a minimal project running.

I honestly have no idea how feasible it is to port it to such system.
If SDL3 already works, then technically it should be possible if you have a working c++17 compiler. I'm more concerned about the available RAM though, TGUI is not optimized at all for low memory usage. So I'm concerned that the gui will use too much RAM for such a system.

Do you know how to cross-compile for the ESP32 with CMake? TGUI relies on CMake as build system, so if CMake is supported when building for ESP32 then it would be significantly easier to port.

The two places that I know that might need changes to OS detection are https://github.com/texus/TGUI/blob/1.x/cmake/Config.cmake#L1 and https://github.com/texus/TGUI/blob/1.x/include/TGUI/Config.hpp.in#L35
Initially I would just define TGUI_SYSTEM_LINUX/TGUI_OS_LINUX and see how far the compilation gets. If you get errors because about missing Linux stuff then you could try looking for workarounds, but if it's POSIX then maybe most just works (TGUI does very little platform-specific things).

I reproduced the crash here. Your mistake is that you are creating a global sf::RenderWindow.
You should never create SFML or TGUI objects globally. Having global pointers to them is fine, but you should always make certain that the constructors are executed after the WinMain function begins and destructors are executed before the WinMain function exits.

I moved the following two lines from global scope to the top of the WinMain function:

Code (cpp) Select Expand

sf::RenderWindow window(sf::VideoMode(sf::Vector2u(800, 600)), "Disk Manager", sf::State::Windowed, sf::ContextSettings());
tgui::Gui gui(window);I then had to replace some "gui" references inside the setupWidgets function to "ui". After that your program compiled and started fine.

The pdb file itself isn't useful for me.
In the callstack you can see there are line number for the bottom lines because those are from your own program (e.g. line 76 was where you created the window). Those line numbers are known because you have that Filescanner.pdb file.
There exist pdb files for your SFML libraries as well. If you copy those files to the same place where you found your Filescanner.pdb then the callstack will show line numbers for all those lines in the callstack that came from inside the SFML library. So by including the pdb files from SFML into your project you would get a more detailed call stack (right now the callstack shows a crash inside the sf::JoystickImpl::updateConnectionsDInput function, but it doesn't exactly specify at which line of that function).

If you can bundle your entire project into a single zip file (including SFML and TGUI folders), so that it can be build on a computer without needing to download or install anything else (except Visual Studio, that is already installed), then I'm willing to see if I get the same issue when running it here or not. If I can reproduce it here then I should be able to fix it.

Do you have any joysticks connected? If so, does it help when they aren't connected?

The callstack looks a bit weird though. The deviceObjectEnumerationCallback isn't called from updateConnectionsDInput. The function also doesn't use a vector. So at least the top entry in the call stack seems like it might be corrupted. Could you copy the "sfml-*.pdb" files from SFML next to your exe? If you downloaded the SFML libraries then you can find these .pdb in the lib/Debug folder, otherwise they were created where the .lib files were created. With those pdb files the call stack should contain line numbers, which would give a more accurate point in the SFML code where the error occurs.

The error happens while creating the SFML window, so this doesn't seem to be related to TGUI. Do you get the same error when you don't link TGUI in your project? If the issue remains when removing TGUI (which I don't think is likely) then it would point to some compatibility issue with the linked TGUI and SFML libraries. If the issue remains then this is clearly an issue with SFML. Since I've never seen a crash at that location, you may want to ask the SFML team about it (e.g. on their Discord) and share the callstack and error message with them, maybe they can make some sense of it.

When it crashes, you should be able to get a call stack in Visual Studio.
That will tell you on which line in your code it crashes. I may be able to help you further if you can share the call stack.

Are you maybe mixing release and debug libraries (e.g. linking to libraries ending at "-d" in release mode)? That's could cause weird unexplainable crashes.

It's not possible with TGUI directly. You should add a Canvas widget to the panel and somehow render your gaussian blur on that canvas.

Assuming you use the SFML_GRAPHICS renderer: if you can get the wanted effect in SFML with an sf::RenderTexture, then you can get the same effect in TGUI by replacing the sf::RenderTexture with a tgui::CanvasSFML

Animated textures are not supported directly.

You would have to load each frame into a texture and then call the getRenderer()->setTexture() function with a different texture each time you want to update the visible frame.

What do you mean with "dynamic image support"? Just changing the texture?

You can change the texture in the widget renderer:

Code (cpp) Select Expand

picture->getRenderer()->setTexture("image.png");

The theme doesn't contain a section for your custom widget, so the BackgroundColor and TitleBarColor in the renderer are never set. No value is apparently transparent here.

In your constructor code you have 'getRendererNoThrow(m_type)', I guess if you change it to 'getRendererNoThrow("ChildWindow")' then it would load correctly.

Alternatively, the Theme class has a few static functions to allow specifying relationships between widgets. I'm guessing you need 'tgui::Theme::addRendererInheritanceParent("YourCustomWidgetName", "ChildWindow");' somewhere before creating the widget to tell the Theme to fall back to the "ChildWindow" section for your custom widget type if no more specific section exists.

Do you need to assign an id to each item (i.e. second parameter of addItem function)? If not then you can use "addMultipleItems" (added in TGUI 1.6) to add all items at once.

For changing an item, are you using changeItem? That function has to loop through all items to find a matching string, changeItemByIndex is much faster if you know the index of the item that needs to be changed.

I'm not sure if a combo box with so many items is a user-friendly UI design though.

The thing to note it that TGUI technically isn't stealing your event. The handleEvent function just returns true, and your code is deciding not to handle the event if that is the case.

It's very difficult for me to decide what handleEvent should return. On one hand, people would only expect it to return true when the key event was actually used, but on the other hand you might not expect it to return false when an edit box is focused and you press backspace while the cursor is at the front or you try to type text in a numeric field.

The return value of handleEvent is something that can help your code decide whether it still needs to process it separately from the gui, but it doesn't has to be the only check. For example you could only execute the "continue;" line if the event wasn't a controller input, or even skip gui.handleEvent altogether for controller inputs.

So you should probably try to first think about when a key event should be handled by your code and when it should be dealt by the GUI. If you can properly define a rule about where the event needs to go to, then it might be more clear for me what you need exactly in case you are stuck implementing it.

Key events are only send to the focused widget (and its chain of parents). There were a handful of widgets (like Picture and Canvas) that I considered "unfocusable". Since they never get focused, they never receive the key events. This isn't really documented properly anywhere, I never expected someone to inherit from these classes and turn them into functional widgets instead of just drawings.

You can fix your code by adding the following function to your class:

Code (cpp) Select Expand

bool GameCanvas::canGainFocus() const override
{
    return true;
}

Of course you will only receive the key presses after you clicked the canvas or called canvas->setFocused(true), and you will no longer receive them once the user clicks on a button and the button receives focus. If this isn't what you want, then you should process the key events somewhere else. Either in your event loop, or make a Group/Panel widget that contains all other widgets and already handle key presses in that container.

With TreeView you could collapse things in your code when receiving a callback from onExpand.
Smooth transitions is something that isn't supported and won't be possible unless you write it yourself entirely.

Is StateManager above or below the Gui in the declaration of Game?
Could you try placing the Gui object as first member in your Game object?

Could for some reason the m_registeredFonts vector be empty?

That wouldn't cause any issues. If it crashes in "Backend::unregisterFont" then it means that the backend is a nullptr and accessing m_registeredFonts is invalid.

If you print a line at the very end of your main function, does it get printed before it crashes?
I'm guessing the line gets printed and there is still some Font object that hasn't been destroyed yet.

Edit: depending on how much time you are willing to put in this, and what you really want out of the upgrade, maybe it would be better to only update to TGUI 0.8 for your existing project, which is similar enough to 0.6 while still supporting the latest SFML 2 version.

it won't load the SFML libraries because they're not signed correctly

I vaguely remember that you had to go into the macOS settings somewhere and press a button to add an exception for the unsigned library. And you had to do the whole thing once for each library (i.e. separately for sfml-system, sfml-window and sfml-graphics). But maybe there is some setting in xcode to completely disable this security.

Now I get BAD ACCESS errors from my class destructors that use TGUI. Does 1.6.1 require explicit cleanup steps that 0.6 didn't?

It doesn't require explicit cleanup, but no TGUI widgets or textures are allowed to exist anymore after the backend is destroyed (which happens when calling setBackend(nullptr) or in the destructor of the Gui object if you don't manually create a backend). If TGUI objects still exist afterwards then their destructors would crash at the end of the program.

Porting old code to fit these new restrictions can of course be annoying. If you write new code then it would immediately give you an error when doing something like that, and you know you have to change the code that you just wrote. When porting existing code it might be more difficult to find the issue and potentially redesign it a bit to make things execute nicely.

Are there any other things I need to change?

None that I can think of.

Is it viable to have a Game class with `tgui::Gui  gui;`  and then call `gui.setTarget([RenderWindow&])` in the class constructor?

Yes. You just have to be careful about which objects you put in the same class.

TGUI is only fully constructed once you make the setTarget call. Suppose the class containing the Gui is called Game. If Game contains a member called MenuScreen, then the constructor of MenuScreen will execute before the constructor of Game. So if inside the MenuScreen constructor you call tgui::EditBox::create(), then you would have an issue.

I imagine that your issue is similar to the case described above.
Alternatively, maybe the class that contains the Gui is a global variable? That could also cause serious issues (although you probably would have already faced some before in that case).

Ideally you would create the Gui at the correct spot to avoid issues. If for some reason it is too difficult: there is a way to manually construct the TGUI backend. By default the Gui creates the backend internally to reduces the amount of work you have to do, but it has the downside of complicating the lifetime of the backend.
An alternative is thus to manually create the backend object. This can be done before the SFML window is even created, so you would essentially just put the following as the very first lines in your main function:

Code (cpp) Select Expand

auto backend = std::make_shared<tgui::BackendSFML>();
backend->setFontBackend(std::make_shared<tgui::BackendFontFactoryImpl<tgui::BackendFontSFML>>());
backend->setRenderer(std::make_shared<tgui::BackendRendererSFML>());
tgui::setBackend(backend);
At the very end of your main function you would put the following line:

Code Select Expand

tgui::setBackend(nullptr);

When creating the backend manually like that, you can work with widgets before the Gui is constructed without any issues.

[check where you are passing the window to the gui. This is the moment that the backend will be created, all widget creations should happen later]

I checked the code and it seems like there is no error in Release mode when attempting to use a backend that doesn't exist. If TGUI is built in debug mode then it would print something to the terminal and terminate.

The bad access happens on address 0x30, such a low address means that it tried to dereference a nullptr.
With that call stack, the only explanation that I see is that the backend would be a nullptr.

Try printing the value of "tgui::getBackend()" before creating the edit box. If my theory is right then it it will be a nullptr and calling "tgui::isBackendSet()" will return false. If this is the case then check where you are passing the window to the gui. This is the moment that the backend will be created, all widget creations should happen later. This restriction was added in TGUI 0.9 (when making the library work with other backends than SFML) so the old TGUI versions had no problems with creating widgets earlier.

Not all widgets create their resources immediately, which could explain why creating some widgets do work. I imagine that e.g. RadioButton will also cause the crash.