1

Feature requests / Re: Rounded borders for containers

« on: 15 November 2021, 22:44:21 »

The setRoundedBorderRadius function has been added to PanelRenderer in TGUI 0.9 and 0.10-dev.

I did notice one other limitation though. Since TGUI can only clip rectangles, widgets inside the panel can still be drawn outside the rounded corners (if you place a widget there).

The 0.10-dev downloads on the download page have been updated. If you don't use Visual Studio or want TGUI 0.9 then you will have to build TGUI yourself (with the source code from github).

2

Feature requests / Re: Rounded borders for containers

« on: 15 November 2021, 19:09:12 »

It's not in TGUI yet, but it indeed shouldn't be hard to add.

I didn't want to add rounded borders to all widgets because with the current design it would be a lot of copy-pasting work and requires changing each individual widget. The idea was to first redesign the widgets so that they are rendered with reusable components. Adding rounded borders then would immediately make it available for all widgets. But the redesign had some issues and was delayed.
Because all previous requests about rounded borders were about the button widget, I decided to add setRoundedBorderRadius to the button renderer to at least allow using it for the most common use case.

Do you only need it for the Panel widget?
Does it matter that the mouse events still treat the widget as a rectangle for now? (Because ignoring the mouse events when on the corners seems to be only implemented when using textures, even for the button widget)
Then I can quickly add that to TGUI.

3

Help requests / Re: Replacement for tgui::Canvas in SDL backend

« on: 07 November 2021, 14:28:51 »

For anyone that sees this in the future: the situation is now completely different.

SDL 2.0.17 has added a SDL_RenderGeometry function which makes it possible to use the SDL_Renderer for all rendering instead of requiring OpenGL directly.

TGUI 0.10-dev now also has an SDL_RENDERER backend which makes use of this functionality. A CanvasSDL class has just been added to this backend to which you could draw SDL_Texture objects:

Code: (cpp) [Select]

SDL_Texture* imgTexture;  // The image to render to the canvas

auto canvas = tgui::CanvasSDL::create({400, 300});

SDL_SetRenderTarget(renderer, canvas->getTextureTarget());  // Let drawing happen on the canvas instead of the window
SDL_RenderClear(renderer);                                  // Clear the contents of the canvas
SDL_RenderCopy(renderer, imgTexture, NULL, NULL);           // Draw an image to the canvas
SDL_SetRenderTarget(renderer, nullptr);                     // Let further drawing happen on the window again


4

Help requests / Re: Read Access violation error when getting widget pointer from loaded gui

« on: 24 October 2021, 14:35:19 »

setSize is implemented in Button while isMouseDown is implemented in the Widget base class. If the first one crashes while the other does not then it may imply that the object is a Widget but not really a Button.
Since your code works here, I'm starting to wonder if there might be some library incompatibility that causes the Button class in your code to be different from the Button class in TGUI code.

Did you compile SFML and TGUI yourself or did you download precompiled versions from the websites? Which visual studio compiler are you using exactly? Are you certain you aren't linking to Debug libraries while in Release mode, or vice versa?
I noticed you mentioning debug mode but also mentioning tgui.dll, which is the release dll. Make sure to use the library with "-d" postfix in debug mode (for both SFML and TGUI).

5

Help requests / Re: Read Access violation error when getting widget pointer from loaded gui

« on: 24 October 2021, 14:14:00 »

What is the contents of startMenu.txt? Are you certain it contains a button with the name "loadFromFile" or "a"?
The access violation happens on a nullptr, which is what the get() function returns when no widget exists with that name.

6

Help requests / Re: ChildWindow close

« on: 01 October 2021, 12:46:17 »

The behavior in TGUI 0.8 was too surprising for a lot of people so it was changed to a new system.

When the close button is pressed, onClosing event is triggered which has a boolean as parameter that you can set to true to prevent the window from being closed.
If there are no signals connected to onClosing or none of them set the abort parameter then the onClose event is triggered. After this event the window will be "destroyed" (i.e. removed from the parent with parentGroup->remove(childWindow)).

Instead of toggling the visibility you could just call group->add(childWindow) again when you need to show the window again.

Alternatively, you can prevent the window from being closed in the onClosing event and change the visibility there:

Code: [Select]

childWindow->onClosing([=](bool* abort){
    *abort = true;
    childWindow->setVisible(false);
});

7

Help requests / Re: Group events

« on: 24 September 2021, 12:24:16 »

That function was never intended to be used directly in previous versions of tgui.
If your group is part of the gui then gui.handleEvent should pass the event to the correct group.
In what scenario do you think you need to pass the event to the group directly?

8

Help requests / Re: ListView removeItem error

« on: 02 September 2021, 22:26:01 »

removeItem apparently shouldn't throw out_of_range even when a wrong index is provided, but I did notice something else in the code that could go wrong.

removeItem() will remove the selected item and thus cause the selection to change. The onItemSelect is triggered halfway through the removeItem() call, so your updateGui is called while removing the item. I'm guessing the updateGui function probably does something with the list view which causes the error.

9

Help requests / Re: ListView removeItem error

« on: 02 September 2021, 18:17:25 »

What is the value of listView->getSelectedItemIndex() inside the onMousePress function? Is there any chance that it is -1 when it throws (which is the case when no item is selected)?

10

Help requests / Re: What do i need to know to use TGUI ?

« on: 09 August 2021, 16:43:43 »

Understanding std::function and lambdas is useful for the signals in TGUI (since examples often use lambdas to keep the code shorter).
Understanding smart pointers (e.g. shared_ptr) is useful to work with TGUI widgets (since Widget::Ptr is just an alias for std::shared_ptr<Widget>).
Other than that, a basic understanding of c++ is required, but you might be able to learn it as you go.

The tutorials (https://tgui.eu/tutorials/0.9/) and example codes (https://tgui.eu/examples/0.9/) provide some useful information.

menu->connectMenuItem("File","Exit",[&]{ window.close(); }); should work fine. Do you have a case where it doesn't work?

11

Help requests / Re: Grid with padding with non-default font size works incorrectly

« on: 03 August 2021, 18:32:20 »

I'm not sure what the best fix would be for this case.

The height of the grid is set to 20% of the panel, which fills the window (which has a height of 400 pixels), thus the grid only has a height of 80 pixels.

You are adding 25px padding above the labels and between label and edit box.
With a character size of 20, the label has a height of 27px and the edit box of 22px.
The total height of both rows is thus 99px.

The hover only looks at the top 80px because it considers everything else to be outside the grid, while the rendering doesn't perform any clipping and thus renders the last 19px as well even though they lie outside the grid.
The most correct solution based on the current code would actually be to add clipping to the rendering and not draw the bottom part of the edit boxes.

12

Help requests / Re: problem running 0.9

« on: 07 July 2021, 18:48:48 »

Yeah, the precompiled TGUI libraries from the website are only compatible with the SFML 2.5.1 release. When using an SFML snapshot then you must build TGUI yourself from the source code.

13

Help requests / Re: problem running 0.9

« on: 07 July 2021, 15:59:12 »

Where did you download SFML and TGUI?

I'm guessing that TGUI was build with a different SFML version than the one you are using in your project.

14

General Discussion / Re: Missing some classes in Doxygen docs

« on: 15 June 2021, 20:00:08 »

I didn't know about the DOXYGEN define, that might come in handy some day.

Once the new backend system is released I'll see whether it will be easier to put all backends in the PREDEFINED field or change the code to check DOXYGEN everywhere.

For now I was going to build only the documentation of the SFML backend (since this is what almost everyone used) by just adding the TGUI_HAS_BACKEND_SFML to the Doxyfile.
I just realized that it isn't enough those, the Gui class isn't missing because it is behind an ifdef like the Canvas class, it is missing because the directory containing the heading isn't part of INPUT. So I might wait until after 0.9.3 to determine which files need to be in the documentation (all of them probably, once I'm done reorganizing).

This will define these both only for Doxygen, so you can leave your compile settings as they are

This reminds me that I should probably check other defines as well instead of leaving them to whatever the settings were on the last build. The TGUI_COMPILED_WITH_CPP_VER for example should probably be set when building the documentation so that any functionality with the latest c++ standard is always shown (e.g. for string_view conversion functions in String class).

this method won't include the code within both an #ifdef and any associated bare #else

I don't think that will be an issue, such cases shouldn't exist for the TGUI_HAS_BACKEND_XXX defines (and the few cases where they do exist are probably all inside the source code and not inside headers).

15

Help requests / Re: Grid and scrollbar

« on: 15 June 2021, 19:30:51 »

I think I might even be talking about a different issue, I though the problem was that the horizontal scrollbar appeared and your 50% width wasn't working correctly.

The vertical scrollbar isn't going to work when you set the grid size to 100%. The size of the grid should depend on its contents or be a chosen size, you shouldn't limit it to the viewable area of the scrollable panel (which is what 100% does). You'll want the grid size to be larger than 100%, because otherwise there will never be anything to scroll to. If you don't call m_grid->setSize then you will see that the vertical scrollbar works as intended (the columns in the grid need to be given a different width in that case though as auto-sizing puts the columns too close to each other). If you call "m_grid->setSize({ "50%","150%" });" for example then the vertical scrollbar can scroll to all contents (but you would have to set the policy of the horizontal scrollbar to Never to not overlap with the last edit box due to the issue I described in my previous post). There is no space below the last widget in the grid, but this could be solved by either specifying a bottom margin when adding it to the grid or manually setting the content size to something larger than the grid size (maybe setting a padding in the scrollable panel might also work, I haven't checked).

Issues like this really expose how TGUI started with having everything at fixed coordinates and where relative positions/sizes are just hacked on top of that instead of the library being designed with dynamic sizes in mind.