Recent Posts

Pages: 1 [2] 3 4 ... 10
Help requests / Re: Best practice for rendering specific widgets
« Last post by texus on 18 August 2019, 09:13:49 »
Two simultaneous gui objects is definitely a bad idea as you could get 2 focused widgets and in case of overlapping widgets both guis may believe that the mouse is on their widget.
Rendering only some of the widgets is also not possible.

The only option you really have to mix tgui and sfml rendering is to use the Canvas widget. The canvas is a wrapper around sf::RenderTarget, so you have to clear() it then draw and then call display() on it. When calling gui.draw(), the sfml rendering you did on the canvas will be displayed inbetween the tgui widgets, depending on which widgets are in front and behind the canvas.
Help requests / Re: Menu doesn't expand(menu items don't show) from layout.
« Last post by Kvaz1r on 18 August 2019, 01:08:51 »
Yes, I'm used to menu bars that separate from frame so idea put it to layout was attempted make it works. At begin I didn't use layout at all and there was my mistake.

Yeah moveToFront works well, thanks for answer.
Help requests / Best practice for rendering specific widgets
« Last post by Hexade on 17 August 2019, 23:56:26 »

When drawing the GUI with draw() it draws all widgets stored within the GUI. At the moment my code looks like this:
Code: [Select]

Where I have implemented a state machine so that each state has control over the sf::Texts and sf::Sprites being rendered. The issue that I am having is that I am rendering text that needs to go on top of a widget, but since I am rendering the GUI after the text, the widget is being drawn on top of the text preventing you from seeing it. I did get around this in an earlier project by simply creating a second GUI so that I could store the overlapping widgets within the second GUI and render that prior to rendering the text. However I have read in past forum posts that you probably shouldn't be creating multiple instances of tgui::Gui.

So, I am wondering what is the best way to go about controlling when specific widgets are rendered (like how I am controlling the text / sprites being rendered with the state machine) rather than having them all render at the same time. Thanks.
Help requests / Re: Menu doesn't expand(menu items don't show) from layout.
« Last post by texus on 17 August 2019, 22:41:06 »
My explanation is wrong for this case. I had a better look at the code and it should only have clipped if you have more than 1 menu item. The first menu item still falls within the vertical layout and could thus still be visible. The reason why it isn't visible is because the button is drawn in front of the menu bar. Try adding the following at the end:

In the future I will likely make menus work like the list of a combo box and always bring it to the front when opened, but for now the menus are part of the MenuBar widget itself and they thus have the same z-value.
Help requests / Re: Menu doesn't expand(menu items don't show) from layout.
« Last post by texus on 17 August 2019, 22:35:21 »
It could be considered a bug, but the layouts simply weren't designed for something like this. Layout widgets such as VerticalLayout are just container widget, so they will clip everything outside their size. The size of a menu bar is only the size of the bar itself, so all of the menus fall outside of the visible area of the container and are thus clipped.

You simply can't have a menu bar in a vertical layout. The only reason that I can think of where it is useful to put it in a VerticalLayout is if you want to have a panel underneath it that fills the rest of the screen so that all widgets inside that panel can have a top position relative to the bottom of the menu bar. In that case you will just have to manually give that panel a position and size (which might actually be easier because you can use an absolute size for the menu bar height instead of a ratio).
Help requests / Menu doesn't expand(menu items don't show) from layout.
« Last post by Kvaz1r on 17 August 2019, 20:02:43 »
Menu items don't show when I press on a menu. Menubar is added into layout. Is this expected behaviour or bug? If it's first case - how to fix?


Code: [Select]
#include <TGUI/TGUI.hpp>

int main()
sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI window");
tgui::Gui gui(window);
auto topLayout = tgui::VerticalLayout::create();
topLayout->setSize("100%", "10%");

tgui::MenuBar::Ptr menuBar = tgui::MenuBar::create();
menuBar->addMenuItem("File", "New");


while (window.isOpen())
sf::Event event;
while (window.pollEvent(event))
if (event.type == sf::Event::Closed)

gui.handleEvent(event); // Pass the event to the widgets

gui.draw(); // Draw all widgets
Feature requests / Re: TGUI builder 0.8.5 - missing vertical slider
« Last post by Hexile on 11 August 2019, 16:42:25 »
hmm, okay. It might be worth adding an "obsolete section" in the docs then, in case there is more things no longer supported.
Feature requests / Re: TGUI builder 0.8.5 - missing vertical slider
« Last post by texus on 11 August 2019, 16:32:44 »
Actually the Slider2d widget no longer exists. In 0.7 it seems like it was still in an extra folder (together with AnimatedPicture and SpriteSheet), but these 3 "widgets" were removed in 0.8. They didn't fully fit in a gui library and I decided that I wasn't going to keep maintaining them (since every version update required rewriting a lot of code in all widgets).

It wouldn't really solve the issue with detecting where the mouse is. The Slider2d class just acted as one big rectangle and would absorb all mouse events in that area, even if your diagonal slider would only fill a small part of that area. The changes required to Slider2d are so large that you might as well just create a new widget for it

If anyone comes up with the necessary code to make rotation work then I would of course merge it, but I have no intention of writing it myself on short term.
Feature requests / Re: TGUI builder 0.8.5 - missing vertical slider
« Last post by Hexile on 11 August 2019, 16:18:13 »
Supposedly, it could be made working using slider 2d and clamping the xpos to something determined by the ypos.
Or at least I think it should be...

I understand it wouldn't be easy to add full rotation support, but it's nice to hear your thoughts on that feature.
Feature requests / Re: TGUI builder 0.8.5 - missing vertical slider
« Last post by texus on 11 August 2019, 10:26:44 »
The problem isn't going beyond 45°, any angle that can't be divided by 90 is problematic. If an object has to be rotated, around what point should the rotation take place?
Imagine you have a slider of 400 pixels width and 20 pixels height. The slider is places on position (100, 100).
- If you rotate 90° clockwise around the top-left corner then the new top-left position will be at (80, 100).
- If you rotate around the center of the widget, a rotation of 90° will put the top left of the slider on position (290, -100).

What I do in TGUI is correct the offset and move it back to position (100, 100). In the first case (which is what TGUI uses), I simply add 20 pixels to the left position of the slider before the rotation even happens. After the rotation the slider will end up rotated 90° and at position (100,100), which is what the user asked for.

But what happens if you rotate by 45° (or even just 1°), what is the top left position then? I could take a bounding box around the entire widget, but that box would change size for every degree you rotate, so the result will be that the slider position is unpredictable and you have to experiment a bit to find the best position for the slider.

The only way that I see to properly support it, is if I let the user set the position of the center of the widget instead of the top left position. That way you could rotate around any angle and the center would remain on the same spot, hence the result of where the slider will end up would be is predictable.

Another problem is going to be detecting when the mouse is on top of the widget. Right now there are only a handful of widgets that can be rotated and the 90° rotation makes it easy to check the mouse position. If a widget can be freely rotated around any angle, checking when the mouse is on top of the widget (and on which part) gets more difficult.

So although the feature would be nice to have, I currently have no plans to add something like that in TGUI as it involves a lot of work.
Pages: 1 [2] 3 4 ... 10