Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: [1] 2 3 ... 109
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;

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?

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.

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

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 ( and example codes ( provide some useful information.

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

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.

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.

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.

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

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.

Help requests / Re: Grid and scrollbar
« on: 15 June 2021, 18:50:37 »
This is because the inner size of the ScrollablePanel never changes when scrollbars are visible or not.
I agree that this isn't ideal and it should probably be changed, but right now it is the expected behavior.

Implementing this properly is a bit tricky: whether scrollbars are shown could depends on the widgets inside the panel, but the size of those widgets would depend on whether there are scrollbars.
So when writing the ScrollablePanel widget I decided to just keep it simple and ignored this case.

Edit: Maybe I could change the inner size when Policy::Always is specified and leave the more difficult case for later.

General Discussion / Re: Missing some classes in Doxygen docs
« on: 15 June 2021, 08:19:29 »
Thanks for letting me know. I guess I should enable the TGUI_HAS_BACKEND_SFML define next time I build the documentation.

For TGUI 0.9.3 I'm planning to rewrite the backends anyway, so I'll add a note that I have to look at improving the documentation (to make Gui classes from all backends show up).

Help requests / Re: ToolTip Auto Position On Screen
« on: 11 June 2021, 19:42:23 »
The TGUI version from github now places the tool tip so that it doesn't fall (partially) outside the window.

Help requests / Re: ToolTip Auto Position On Screen
« on: 09 June 2021, 22:40:19 »
It's currently not possible.
I might have a look at implementing this in the next few days. It doesn't look that difficult, I think this line just has to check if the position plus size of the tooltip is larger than the size of m_view.

Installation help / Re: Help getting TGUI running - OpenGL
« on: 02 May 2021, 22:53:22 »
I can't help you with that IDE. The only thing I know is how the command that is passed to the linker should look like: for dylibs it should be "-lXXX.dylib" while for frameworks it should be "-framework XXX".

To find a different SFML version you have to change the SFML_DIR option. The value has to be the directory that contains a file called SFMLConfig.hpp. I can't tell you which folder this is, as it depends on your SFML installation, but suppose SFML is installed to /usr/local then the folder would most likely be /usr/local/lib/cmake/SFML.

Alternatively you could always install SFML and TGUI using homebrew.

Pages: [1] 2 3 ... 109