Messages

I'm assuming the message in the thrown error is about no backend existing?

You must first create a Gui object and attach a window to it before you are allowed to create any widgets. Otherwise the widgets can't create textures or texts.

In the latest TGUI version, gui.handleEvent will now return false when the event is for a different window.
I didn't put it behind an option, the filter is always enabled.

Apparently SDL3 added a SDL_GetWindowFromEvent(event) function that you can use to determine which window the event came from (and thus you can use that to forward the event to the right gui, or forward it to both guis when the function returns NULL).

No. If you want something like that then I'm afraid you will have to create it yourself.

But it would be better to implement this in TGUI

Since TGUI already has to handle each type of event separately, it should indeed be possible to do the filtering inside "gui.handleEvent".

The only issue with it, is that it would become harder to add fake events (e.g. create your own mouse move event and passing that to the gui). So I'll add the filtering to TGUI, but I might put it behind some option that you need to enable first to keep the filtering on windowID disabled by default.

The closest thing that I have is an older example that I once wrote: https://tgui.eu/tutorials/0.9/sdl-backend/#multiple-windows (it's for TGUI 0.9 which is why it e.g. uses GuiSDL instead of just Gui)

You basically need the correct OpenGL context selected whenever interacting with the gui (with SDL_GL_MakeCurrent in SDL2), and you need to use the windowID in the events to figure out which gui they belong to.

I just noticed that the example code actually contains a mistake. It accesses event.window.windowID but that is only allowed for window events (e.g. windows resize). Other events (e.g. SDL_KeyboardEvent) also contain a windowID property though.

I don't recommend using different threads for this though. TGUI code can only be accessed from one thread at a time (so you can't be handling events or drawing on both threads at the same time). You would need locks everywhere. Also OpenGL isn't really thread-safe. You need to activate the correct OpenGL context (with SDL_GL_MakeCurrent) before rendering, so you can't render with both threads at the same time even if TGUI was thread-safe.

TGUI has nothing for time or date picking.

Can you explain a bit more what exactly you would want though? I'm imagining you mean something like a date picker that looks like the attached image?

It is a Windows-issue in the sense that it is a Windows call that hangs during resize. All window libraries will face issues with it, but a library like QT will have workarounds to make things work. In the SFML github issue they also mention some of the things that they can do to make it work in the future.

Other libraries have the same issue, e.g. GLFW's glfwPollEvents also hangs (e.g. https://stackoverflow.com/a/56614042 describes a method to redraw when the mouse is moved during resizing).
SDL recently worked around it by allowing you to bind a SDL_EVENT_WINDOW_EXPOSED callback that would get called during resize (and in which you can then render (see e.g. https://github.com/libsdl-org/SDL/issues/1059).

I have not experimented with any of these workarounds in combination with TGUI though. Although it should be the exact same as rendering otherwise: you call gui.draw() inbetween the locations where you are clearing and displaying the window contents.

As for which backend is the best. For most people either one will work, there are only minor differences. While I love SFML, it is the one that is the least feature-complete and lacks some advanced functionality, while SDL is commonly used in many places so it probably has the most options that can be tuned to get what you want.

I'm assuming you are using the SFML backend and are using Windows? (other backends might have a similar issue though)

This is a known issue in SFML that is related to how resizing works on Windows. See e.g. https://github.com/SFML/SFML/issues/3016

Unfortunately I don't know any way that I can render it better.

You should use a transparent image that contains the rounded borders and set that as the background texture of the panel. That way, you would get smooth borders due to the borders being anti-aliased when creating the image. You can use TGUI's 9-slice scaling to use the image with any container size (as long as the border thickness is the same).

The minimal information on how to use the canvas is located at https://tgui.eu/tutorials/latest-stable/canvas/#canvasopengl3

After you created the canvas and added it to the gui, you would have the following code to render to the canvas. The contents of the canvas is then later drawn to the window when you call gui.draw().

Code (cpp) Select Expand

canvas->bindFramebuffer();  // Calls glBindFramebuffer with the id of the canvas framebuffer
glClear(GL_COLOR_BUFFER_BIT);
// OpenGL calls placed here will draw on the canvas
glBindFramebuffer(GL_FRAMEBUFFER, 0);

The purpose of the CanvasOpenGl3 widget is to render custom OpenGL stuff in the middle of TGUI widgets. It thus makes no sense to render TGUI widgets on the canvas.

The purpose of the Canvas widget is so that you can render custom raylib draws into a TGUI widget. So no, you can't render TGUI stuff into a canvas, the widget does the exact opposite.

If you wanted to draw TGUI to a raylib RenderTexture and then draw that that texture to the screen later, that could technically be done. However you end up with issues where mouse coordinates are wrong because TGUI can't know where on the window you would be rendering the texture.

So if you want TGUI to only render to a part of the screen then you should check out setAbsoluteViewport or setRelativeViewport (and maybe also look at the setAbsoluteView and setRelativeView function to see if you need those or not)

The gui object is being created in your code before InitWindow is called. This causes it to think that the window is 0x0 pixels, which prevents rendering.

I can get the gui to render something if I call InitWindow before creating the Game object.

"m_ui.draw();" should not be placed between BeginTextureMode and EndTextureMode. You trying to render the entire gui (including the canvas) onto the canvas widget and are drawing nothing to the window.

I placed the "m_ui.draw();" line below "EndTextureMode()" and it crashed here, but I haven't checked yet if that's due to the code or just because I have some other issue in my quickly created test program.

I can load the image in a Picture widget (with the raylib backend) here without any issues. So I have no idea what the issue could be.

Have you tried opening the JPG files with some image editors and re-saving them?
Maybe you can try converting the image to PNG and load that file instead of the JPEG?

Could you attach your Ground.jpg image then so that I can take a look where the loading fails?

Loading images is unrelated to any CMake settings.

Do you get a specific error message when loading the images?
TGUI uses stb_image to load the image as RBGA pixels in memory, and then passes these pixels to raylib. During the automated tests, TGUI loads multiple images from https://github.com/texus/TGUI/tree/1.x/tests/resources which include a .jpg, .bmp and .png image. You would need some special type of image before stb_image will fail to load it.

Have you placed your images in the same directory as the RedBackground.jpg file to rule out the possibility that something is wrong with the path to your images?

raylibdll.lib is the shared library, raylib.lib is the static one.
Trying to set raylib_LIBRARY to raylib.dll is wrong so getting errors in that case makes sense.

If it's only the Color class that is giving the linker error then you can try setting TGUI_CXX_STANDARD to 17 in CMake when building TGUI. I've never seen that linker error before though, it only makes sense to me if you aren't linking to TGUI or if you are incorrectly defining TGUI_STATIC, but in those cases you would get many more linker errors. The error also has nothing to do with raylib, it's purely with linking TGUI itself, so I guess the raylib part is fine now.

Is that the only linking error, or one of many?
Did you add the TGUI library to your linker?
Are you using static or dynamic libraries?

I've updated TGUI to provide an alternative to the raylib-config.cmake file.
You can now use the pre-built package by setting raylib_INCLUDE_DIR to the include folder and raylib_LIBRARY to one of the files inside the lib folder.

Do you use CMake to build raylib? What build system are you using?
On Linux with Makefiles for example, the config file will be created when running "make install". If you use e.g. visual studio then you will probably also have some INSTALL target that you can build.

Edit: you might also want to try setting raylib_DIR to the directory of the config file instead of raylib_ROOT just to be safe (the DIR variable will work with any cmake version, the ROOT version is a newer feature).

This functionality has been added to the Gui Builder.
You can drag a widget to move it to a different parent or to change the order within the same parent.

Are you using SFML or SDL?

Have you tried following either the tutorial for SFML or the tutorial for SDL.

If you are stuck somewhere the please provide some more information on the step you are stuck on and what errors you are getting.

I don't have time to look at this now so I only quickly read your post and I haven't read your code yet, but while what you are trying to do sounds like a very useful feature, it is probably not so simple to do properly.

Note that there actually is already a way to change a widget's parent. You can cut the widget, select the new parent and then paste it.

Is your Visual Studio up-to-date?

If a library is build with e.g. VS 2022 17.5 then it will work for on never versions such as 17.8 but it isn't guaranteed to work on 17.4

Visual Studio Installer tells me that I currently have VS 2022 17.9.4 installed. Assuming I didn't update it since I built the TGUI 1.3 libraries, it means that you might be getting this linker error because your VS 2022 version is older than 17.9