Recent posts

#11

Installation help / TGUI MSVC linker errors

Last post by nikodev - 14 January 2026, 14:56:48

Hello. I compiled TGUI as a static library with RAYLIB backend just fine. However, I get 3 unresolved symbols when I try to link it with my application. I am on a Windows environment.

Output:

Code Select Expand

4>editorInterfaceService.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl tgui::RAYLIB::Gui::~Gui(void)" (__imp_??1Gui@RAYLIB@tgui@@UEAA@XZ) referenced in function "public: virtual void * __cdecl tgui::RAYLIB::Gui::`scalar deleting destructor'(unsigned int)" (??_GGui@RAYLIB@tgui@@UEAAPEAXI@Z)
4>aboutWindow.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl tgui::Texture::Texture(char const *,class tgui::Rect<unsigned int> const &,class tgui::Rect<unsigned int> const &,bool)" (__imp_??0Texture@tgui@@QEAA@PEBDAEBV?$Rect@I@1@1_N@Z) referenced in function "public: __cdecl AboutWindow::AboutWindow(struct Rectangle)" (??0AboutWindow@@QEAA@URectangle@@@Z)
4>..\..\build\windows\x64\debug\editor.exe : fatal error LNK1120: 3 unresolved externals


#12

Feature requests / Re: Porting TGUI to a new oper...

Last post by sgnAudio - 14 November 2025, 10:20:26

wow, thank you. This are great news. Excellent support here. I am a bit busy with the hardware now, but soon I will move to the software side.

#13

Feature requests / Re: Porting TGUI to a new oper...

Last post by texus - 13 November 2025, 20:28:57

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.

#14

Feature requests / Re: Porting TGUI to a new oper...

Last post by sgnAudio - 12 November 2025, 01:00:38

Thanks for your prompt answer.

The C++ compiler supports the C++23 standard with the GNU extensions (-std=gnu++23) by default. The build system is based on CMake to configure the project, manage components, and generate build files for tools like Ninja, which is then used to build the project. The idf.py command-line tool provides a user-friendly interface that manages the CMake build process.

So far so good. Let me try, how far I come with the memory limit.

#15

Feature requests / Re: Porting TGUI to a new oper...

Last post by texus - 11 November 2025, 17:19:04

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).

#16

Feature requests / Porting TGUI to a new operatin...

Last post by sgnAudio - 11 November 2025, 08:49:05

Dear,

TGUI looks very interesting. What steps would be needed to port it to a new OS? I would like to use it on a ESP32, 32MB Ram, dual 400MHz cores, what has already a somehow POSIX like operating system, based on FreeRTOS, with file system, multi-threading ect, and a SDL 3 port. 

I saw Config.hpp.in, can all modifications made in there? I did not see a porting guide, such a document would be great.

Best regards,
Michael

#17

Help requests / Re: Loading Options

Last post by _Mir_.cpp - 17 April 2025, 18:47:07

You can use my workaround. I posted it on this forum.

#18

General Discussion / Loading files from resources

Last post by _Mir_.cpp - 17 April 2025, 18:45:21

I found a workaround to use resources from .exe file on Windows (Microsoft VC++): I used temporary files. We need to add our files to resource.rc and use this code:
At the beginning of the program:

Code Select Expand

#include <fstream> // To save files
#include <stdio.h> // To delete files

// Define some types and functions because if we use Windows.h, an error appears: you cannot override the WinMain() function.
using DWORD = uint32_t;
using LPVOID = void*;
typedef void* HINSTANCE;
typedef wchar_t WCHAR;
typedef const char* LPCSTR;
typedef const WCHAR* LPWCSTR;
typedef unsigned int UINT;
typedef void* HGLOBAL;
typedef void* HRSRC;
typedef void* HMODULE;
extern "C" {
HRSRC FindResourceA(HMODULE hModule, LPCSTR lpName, LPCSTR lpType);
HRSRC FindResourceW(HMODULE hModule, LPWCSTR lpName, LPWCSTR lpType);
HGLOBAL LoadResource(HMODULE hModule, HRSRC hResInfo);
void* LockResource(HGLOBAL hResData);
unsigned int SizeofResource(HMODULE hModule, HRSRC hResInfo);
}
This is my function to save temporary files:

Code Select Expand

bool SaveResourceToFile(const WCHAR* resourceName, const WCHAR* resourceType, const WCHAR* outputFilePath)
{
// Find a resource
HRSRC hResource = FindResourceW(NULL, resourceName, resourceType);
if (hResource == NULL) {
return false;
}

// Load a resource
HGLOBAL hMemory = LoadResource(NULL, hResource);
if (hMemory == NULL) {
return false;
}

// Get resource size
DWORD resourceSize = SizeofResource(NULL, hResource);
if (resourceSize == 0) {
return false;
}

// Get a pointer to the resource data
LPVOID resourceData = LockResource(hMemory);
if (resourceData == NULL) {
return false;
}

// Write data to file
std::ofstream outputFile(outputFilePath, std::ios::binary);
if (!outputFile.is_open()) {
return false;
}

outputFile.write(static_cast<const char*>(resourceData), resourceSize);
outputFile.close();

return true;
}
Now we can do this:

Code Select Expand

SaveResourceToFile(L"#101",L"PNG",L"TempFileScannerIcon.png"); // Saving files
SaveResourceToFile(L"#103",L"TXT",L"TempFileScannerWidgetsList.txt");
// ...
// Using our files
// ...
remove("TempFileScannerIcon.png"); // Removing files
remove("TempFileScannerWidgetsList.txt");
Note that I had some problems with resources with default type (like "Icon"), but may be I did something wrong.

#19

Installation help / Re: Vector error in Microsoft ...

Last post by _Mir_.cpp - 13 April 2025, 19:06:01

Thank you a lot!

#20

Installation help / Re: Vector error in Microsoft ...

Last post by texus - 13 April 2025, 18:49:25

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.