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 ... 107
1
Help requests / Re: How to use file form generated by GUI_BUILDER?
« on: 29 December 2020, 18:58:24 »
You can call gui.loadWidgetsFromFile(filename).
You can also call the function on a Container widget instead of on the Gui, in case you want the form to be loaded inside a child window.

The only place where this is currently mentioned is the tgui homepage. It doesn't belong there, but I placed it there to have it at least mentioned somewhere :)

2
Yes, I meant mouseDownEvent instead of event.

The getWidgetBelowMouseCursor was actually added to 0.8 as well, but its currently only in the 0.8 branch on github (which will become 0.8.9).

3
MouseReleased in ListBox wasn't made for this. It was added so that you could know when selecting an item end (since you can hold down the mouse button and move to select a different item).

Dragging an object on top of another is not really something supported in TGUI. You can drag things (e.g. the thumb of a slider), but until you drop it all events to other widgets are ignored. Since you need special code for dragging anyway, you might as well add some extra code to handle dropping it on the right item. I would just add the following code before the gui.handleEvent call to simulate a mouse down event before processing the mouse release:
if (dragging && (event.type == sf::Event::MouseButtonReleased)
 && (gui.getWidgetBelowMouseCursor({event.mouseButton.x, event.mouseButton.y}) == listBox))
{
    sf::Event mouseDownEvent = event;
    event.type = sf::Event::MouseButtonPressed;
    gui.handleEvent(mouseDownEvent);
}

4
Thanks for reporting and providing a clear MCVE. This has now been fixed in the latest 0.9-dev version.

5
Help requests / Re: Tool Tip Functionning - 1 Tooltip for X buttons
« on: 25 October 2020, 13:09:26 »
The gui builder simply doesn't support tool tips yet.

Quote
This would mean I shouldn't put it in the same file as my main gui ?
You could technically still store it in the main gui, but directly after calling xgui.loadWidgetsFromFile you would have to remove it again:
tgui::ChildWindow::Ptr toolTipChildWindow = xgui.get<tgui::ChildWindow>("child_game_city_construction_tooltip");
xgui.remove(toolTipChildWindow);
// Use the toolTipChildWindow variable directly when calling setToolTip and setTitle.

The loadWidgetsFromFile will always add all widgets to the parent (because otherwise there would be no way to access the widget after calling loadWidgetsFromFile), so if you use a second file then you can't put a ChildWindow widget in there either. The second file would have to contain the contents of the child window (e.g. just a label) and in your c++ code you would have to create the child window yourself, give it a title and size and call childWindow->loadWidgetsFromFile("tooltip_contents_form.txt").

If the contents of the child window doesn't change too much based on the the button you are on then you can use one of the above solutions, but otherwise you might want to create everything dynamically in c++. The gui builder was intended for static forms and even tool tips were designed to be static (one tool tip for each button instead of reusing the same child window). It is possible to reuse the same child window (with a hack such as changing the contents on the the MouseEntered signal), but what you are trying to do was never considered so there is no "correct" solution for it.

6
Help requests / Re: Tool Tip Functionning - 1 Tooltip for X buttons
« on: 23 October 2020, 18:31:23 »
Some parts of the tool tip are automatically handled by TGUI and you shouldn't change them yourself:
- the position (what you pass to setPosition is added as an offset for the tool tip relative to your mouse, it isn't an absolute position like with normal widgets)
- the visibility (you should never have to call setVisible on a tooltip widget, TGUI will show and hide them automatically)
- the parent (i.e. don't call gui.add on the tooltip)

The crash originates from the fact that you have made the child window a part of xgui instead of letting the buttons handle the tool tip.
In order for widgets to show up on the screen, they need to be added to the gui (either directly or indirectly via some container widget). So when the button wants to show the tool tip, it adds it to the gui (which does practically nothing since you already did that). But when the tool tip gets hidden, the button removes the tool tip child window from the gui. So when you hover over the next button, `xgui.get<tgui::ChildWindow>("child_game_city_construction_tooltip")` will return a nullptr and the code crashes as you attempt to call setTitle on a nullptr.

The solution is to not add the child window to the gui (i.e. don't call xgui.add(childWindow) and instead store the child window pointer somewhere so that you can call `button->setToolTip(childWindow)` and `childWindow->setTitle(...)`. This solves both the crash and the wrong behavior where the child window is visible before you hover over a button.

Btw, when you get another crash, you should check the call stack in your IDE, it tells you where the crash happened. This information can save time in searching what went wrong.

7
Help requests / Re: Texture for RangeSlider
« on: 13 October 2020, 08:29:50 »
I think I finally understood what you mean. When textures are loaded, nothing extra is shown inbetween the two thumbs.
I'll try to fix this soon (in TGUI 0.9-dev).

Edit: I've already fixed the SelectedTrackColor property, it should work now even when textures are loaded. I'll look into adding a new SelectedTrackTexture property later.

Edit2: TextureSelectedTrack and TextureSelectedTrackHover properties have been added to RangeSliderRenderer.

8
Help requests / Re: Texture for RangeSlider
« on: 12 October 2020, 08:22:12 »
Quote
RangeSlider is inherited from Slider
It actually doesn't, it just contains mostly the same code.

Quote
I can not set the RangeSlider to display textures (available to Sliders)
What exactly doesn't work? Do you get an error or does is just not show the textures?

I just tried loading the black theme and using the Slider section to create the RangeSlider like below and it worked (it's not recommended to use a section of a wrong type, but it works here because they do support the same properties).
rangeSlider->setRenderer(theme.getRenderer("Slider"));

Quote
There does not seem to be a way to load textures for the space between the two thumbs.
This indeed seems to be missing.
There are 2 ways this could be implemented though. You could have a texture that has the same size as the track and of which only a part is shows (similarly to how the front image in ProgressBar works), or you could have a small texture with the same height as the track which is stretched horizontally to fill the selected area. I guess the first one would be the better option because it can handle rounded corners on the track or other special cases.

9
Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 20:05:12 »
Could it be that C:/Strawberry/c/include/freetype2 is giving a conflict with the freetype that comes with SFML?

10
Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 20:01:39 »
I don't see anything wrong with those files, it says that it has freetype at T:/libraries/C++/SFML-2.5.1/extlibs/libs-msvc-universal/x86/freetype.lib

Did you download the SFML version from github?
You are setting TGUI_SHARED_LIBS to FALSE, right?
Could you send the CMakeCache.txt file from your TGUI build?
Could you send your entire SFML folder?

I'm not sure when I'll find enough time to look into this in detail, but if you send me those files then I'll try to find some explanation when I find the time.

By placing the old code back in TGUI's cmake you are changing the CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH variables and the issue is only solved as a side-effect of this (those lines existed in the cmake script for building the gui builder and tests, not for finding sfml). So although it works, it isn't really the solution (it only works by accident that way).

11
Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 18:48:34 »
Could you send the SFML*.cmake files to me that you have inside your build folder?

12
Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 14:10:28 »
Then were did the SFML folder come from?
SFML doesn't has a SFMLConfig.cmake in the root by default. If you e.g. download it from the SFML website then the file will be in lib/cmake/SFML.
Did you build SFML yourself with CMake? If so, did you create a build directory?
The only case that I can think of where the file would be located there is when you build SFML with CMake and set the build directory to the same as the source directory, but even then it should be able to find freetype.

13
Installation help / Re: Error CMake couldn't find SFML
« on: 19 September 2020, 13:41:57 »
Did you manually copy the SFMLConfig.cmake to a different location, because it seems like SFMLConfig.cmake can't find FreeType? The SFMLConfig.cmake hardcodes relative paths, so you are supposed to keep the SFML folder structure.

The SFML_ROOT method hasn't been recommended for quite some time already (because SFML changed the way you are supposed to find it with CMake), and I don't recommend adding back the code that uses it.

It might work when you put the hardcoded paths back into TGUI's CMake file, but the whole idea of using SFMLConfig.cmake (compared to the old FindSFML.cmake) was that I wouldn't have to hardcode these extlib paths anymore.

14
Help requests / Re: Menu item clicks
« on: 14 September 2020, 17:03:17 »
The connectMenuItem function is still the correct way to do this (and it just calls onMenuItemClick internally). Although it is a bit weird that all other connects are handled by onXxx, it has always been a bit of a weird function (since every other signal used the normal "connect" function while here you needed "connectMenuItem"). I don't immediately see a better way to do it, so connectMenuItem is likely going to remain unchanged.

15
Help requests / Re: How do you connect in 0.9?
« on: 14 September 2020, 16:56:25 »
I'm sorry I didn't reply earlier, but somehow the forum had disabled notifications for this particular topic (while other topics that were created before and after your questions still have notify active for each message by default). I have no idea how that happened. Just for testing, could you perhaps create a new empty topic (which I will delete once I see it). If I don't get a notification for that one either then it must be some setting related to your account while otherwise it was just a temporary issue.

Quote
How do you connect in 0.9? I used to be able to pass a function to listbox->connect("ItemPressed", cb) but I can no longer do this. listbox->onItemSelect.connect(cb); produces an error, as does passing (&cb).
"listBox->onItemSelect(cb)" or "listBox->onItemSelect.connect(cb)" should work. What error did you get, maybe you were still using e.g. an sf::String as parameter instead of tgui::String?

Quote
I see that setView no longer exists and setRelativeView presumably should be used, but setRelativeView doesn't take a sensible obiect that can be converted into the parameter it desires. I can no longer pass in a sf::View, or even the result of sf::View::getViewport() even though it claims it is looking for a FloatRect (error converting between sf::FloatRect and tgui::FloatRect).
Conversion from SFML types to TGUI types sometimes requires explicit casts (because of issues you could otherwise get with ambigous function calls), you would just need to type "tgui::FloatRect(sfmlRect)". Though in most cases you won't need to use SFML types when passing things to TGUI (although it is annoying when upgrading from 0.8 as you did already use SFML types everywhere, which is why I don't recommend upgrading an existing project unless you have to). TGUI now changes the view automatically with the window size, so the most common case to call setView has been removed. Whether you need setRelativeView or setAbsoluteView to set a custom view depends on what parameters you want to give. The documentation of these functions contain a code example (e.g. https://github.com/texus/TGUI/blob/49f818919363d04bd51c87799655d52dfb78e449/include/TGUI/GuiBase.hpp#L113-L117).

Quote
It seems that I need to pollute my code with now-necessary type names in order to get your tgui::String to convert into either sf::String or std::string accordingly. This is very ugly.
I'm not sure I understand what you mean. There are implicit conversions to std::string and sf::String, plus tgui::String has all functions that std::string has, so you shouldn't need to do any manual conversions.
There are only two places where you are forced to make changes to your code: in the parameter of a callback function and when casting an sf::String to a tgui::String (by using "tgui::String(sfStr)") (but casting from tgui::String to sf::String is implicit).

Quote
Could you backport the fixes to the widgets to 0.8 before proceeding any further with 0.9?
I'm willing to backport small changes, but it would be helpful if you mentioned which changes in particular you are interested in.

Quote
Documentation would be really helpful. Do you maybe have a younger brother or a cousin or a neighbour who could do it for you?
I agree, but there is nobody that can do it for me. I've mentioned it online many times in the past that I could use help with it, but nobody else contributes any documentation.
I am currently rewriting the installation tutorials, after which I will write some other useful tutorials. I want to get some minimal information available before I launch 0.9-beta.

Pages: [1] 2 3 ... 107