Messages

There currently is no easy way.
I could perhaps add RightMousePressed, RightMouseReleased and RightClicked callbacks to ClickableWidget though.

The name MousePressed has been in use before right clicks were supported at all, which is why the name doesn't make it clear that it only refers to left mouse clicks.
Support for right mouse clicks is currently extremely limited. Widgets know when the right mouse is pressed with the internal rightMousePressed and rightMouseReleased functions, but ListView is currently the only widget with a RightClicked callback.

What are you trying to do exactly? Would you need a callback on the actual click, or already when the right mouse button goes down?

The "autoscaling" happens with your own SFML drawings too. For this you need window.setView when resizing the window. This doesn't affect TGUI however since it uses its own view, but you basically have to do the exact same thing, but just use gui.setView instead of window.setView.

So to disable the "autoscaling" for both TGUI drawing and your own SFML drawings, you can add the following code inside the event loop:

Code (cpp) Select Expand

if (event.type == sf::Event::Resized)
{
    window.setView(sf::View(sf::FloatRect(0, 0, (float)event.size.width, (float)event.size.height)));
    gui.setView(window.getView());
}

This convert to sf::Image first.

Passing an sf::Texture to TGUI is actually not the best strategy if you want performance, as the texture can't be cached. Each time you pass the same sf::Texture to a function, the code creates a copy of the sf::Texture, assuming it is a completely new texture. Caching the tgui::Texture yourself or passing the filename each time will make sure the same texture is shared the whole time.

If you have a tilemap consisting out of e.g. 16 images, even when passing the filename to setTexture, the code is going to load the image 16 times in total. The cache currently works on both filename and partRect, so if you load a different part then it will reload the image as well. In the 0.9-dev branch that I started a while back but stopped working on, the image would be loaded only once. It would reuse the image and only create a new texture based on the partRect (if you didn't use the rect before), but it couldn't be done in 0.8 for backwards compatibility.

So for now loading different pieces of the same image is always going to be inefficient, but passing sf::Texture directly causes no caching to occur at all so it should be avoided if you care a lot about performance.

It is on the todo list, but it is a complex widget and it probably won't be added anytime soon unless someone else implements it.

Sorry for the later reply, I somehow missed your post.
The setTexture takes a tgui::Texture as parameter which already has the ability to load only a part of an image. Assuming myTilesetTexture is an sf::Texture, you can just do the following:

Code (cpp) Select Expand

btn->getRenderer()->setTexture({myTilesetTexture, {16, 0, 16, 16}});

If I understand it correctly then you are just trying to put the labels on the left size of the cell? If that is the case then you only need to pass 2 more parameters to addWidget (the first one being a padding, the second one being the alignment).

Code (cpp) Select Expand

grid->addWidget(cbox, i, 0, {0}, tgui::Grid::Alignment::Left);

The "&" in ptr->connect("ButtonPressed", [=](const std::string& button) should be an "=".
The lambda is storing a reference to a local value which no longer exists by the time you click the cancel button.
There is no problem in copying the ptr value in the lambda as it is a pointer.

This question comes up occasionally (which is understandable as it isn't documented). The gui builder itself isn't even in the documentation or tutorials so I wasn't sure where to document it, but I have decided to just add a line on the home page, as this is the only place where the gui builder is currently mentioned on the site.

The Group widget is the most basic container widget (a widget that can contain other widgets). Originally this was the Panel widget but it got split up in Group and Panel where the main difference between the two is that Group has no background color. Despite not calling setSize in my example, the group actually has a size and child widgets that would fall outside the group would be clipped.
The default size of the group is to fill the parent widget 100%, so the code that I gave actually makes the bottom part of the group fall outside of the window (as the group was positioned down a bit to start below the menu bar). This doesn't matter in this case, but if you want to rely on bottom padding then you might want to manually call setSize() on the group as well.

VerticalLayout and HorizontalLayout were contributed by someone who found them useful. They are definitely useful for positioning widgets next to each other or below each other, but I would personally only use them for simple cases like having a couple buttons below each other. The gui mostly relies on manually positioning and sizing widgets (either absolute or relative), but these layout widgets are an exception to this. These widgets try to resize and reposition the widgets that you put inside them automatically. This doesn't always perform ideally and some widgets may not work properly when placed inside a layout widget.

So if you need a container of widgets, which you are going to manually give a position, then use Group. It is useful for e.g. creating multiple screens in your program (with each screen being in a group and only one group shown), position a set of widgets relative to some point (like in your case), etc.
If you have a certain amount of space that you want to divide by a couple of widgets, then you can try to use a layout widget.

I tried set position only for layout without using group and this works too.

You can choose. You either add menuBar->getSize().y to the position of all widgets added to the gui or you create a new group widget that has this offset and add all widgets to that group. The outcome will be the same (as long as the group is large enough to fill the screen, which it is by default).

Simply add all widgets other than the menu bar to a group.

Create a group and position it below the menu bar:

Code (cpp) Select Expand

auto group = tgui::Group::create();
group->setPosition(0, menuBar->getSize().y);
gui.add(group);

Remove the lines that add the widgets to the gui

Code (cpp) Select Expand

gui.add(grid);
gui.add(topLayout);

And replace them with adding them to the group:

Code (cpp) Select Expand

group->add(grid);
group->add(topLayout);

It is a pretty complex widget. I'll add it to the todo list, but unless someone else implements it, it won't be added anywhere soon.

The Group::draw function is not supposed to be called directly. With the current design of the gui, you cannot draw widgets directly, all drawing has to happen via gui.draw().
What you are trying to do isn't supported, the gui always draws everything at once, the only solutions that I can provide are workarounds.

The code that you need looks more like this:

Code (cpp) Select Expand

#include "TGUI/TGUI.hpp"

int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "Group Test");
tgui::Gui gui(window);

tgui::Button::Ptr button_1 = tgui::Button::create("Button 1");
button_1->setPosition(5, 5);

tgui::Button::Ptr button_2 = tgui::Button::create("Button 2");
button_2->setPosition(5, 30);

tgui::Group::Ptr group = tgui::Group::create();
group->setSize(400, 300);
group->add(button_1);
gui.add(group);

        tgui::Group::Ptr group2 = tgui::Group::create();
group2->add(button_2);
gui.add(group2);

while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
switch (event.type)
{
case sf::Event::Closed:
window.close();
break;
}

gui.handleEvent(event);
}

window.clear();

group->setVisible(true);
group2->setVisible(false);
gui.draw();

// SFML rendering here will be between group and group2

group->setVisible(false);
group2->setVisible(true);
gui.draw();

window.display();
}
}

Alternatively, using a canvas:

Code (cpp) Select Expand

#include "TGUI/TGUI.hpp"

int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "Group Test");
tgui::Gui gui(window);

tgui::Button::Ptr button_1 = tgui::Button::create("Button 1");
button_1->setPosition(5, 5);

tgui::Button::Ptr button_2 = tgui::Button::create("Button 2");
button_2->setPosition(5, 30);

tgui::Group::Ptr group = tgui::Group::create();
group->setSize(400, 300);
group->add(button_1);
gui.add(group);

// Warning: the default canvas size is (100%,100%) to fill the screen which can cause performance overhead when changing the gui view.
// Set a static size (by passing size to create function or calling setSize) if you don't want it to resize itself when resizing the gui.
tgui::Canvas canvas = tgui::Canvas::create();
        gui.add(canvas);

        tgui::Group::Ptr group2 = tgui::Group::create();
group2->add(button_2);
gui.add(group2);

while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
switch (event.type)
{
case sf::Event::Closed:
window.close();
break;
}

gui.handleEvent(event);
}

// This clear/draw/display code can be called anywhere, if the contents is static you could even do it before the main loop
canvas->clear(sf::Color::Transparent);
// SFML rendering here will be between group and group2
canvas->display();

window.clear();
gui.draw();
window.display();
}
}

What I am trying to render is a tgui::Picture

I'm a bit confused now. You said you wanted to render SFML inbetween the widgets (which is what the Canvas is for)? Why would drawing a tgui::Picture be a problem, it can be placed between any widgets already?

If you want to have states and show different widgets in different states (e.g. different screens), then you should just put the widgets of each screen in a tgui::Group and hide all groups except for the one you want the show. Then when changing screen, you hide the currently shown group and show a different one.

If within one screen you need to draw SFML inbetween TGUI then you either render the SFML on a Canvas and have that canvas drawn within the other widgets, or you do something like billarhos suggested: create 2 tgui::Group widgets, show the first and call gui.draw() then show the second one and call gui.draw() again. You must have access to the group in your drawing code because in your simplified example code you also had some parameter to pass to gui.draw.

I never though of that option, but that would work too.

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.

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:

Code (cpp) Select Expand

menuBar->moveToFront();

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.

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

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.

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.

You would basically just have to read the 0.8 tutorials and relearn how widgets are created now and rewrite the code that deals with the gui.
If you don't want to rewrite your code then you will have to stick with 0.6, there have been 4 active years between those two version so a lot has changed (with most of the changes between 0.6 and 0.7).

Looking at the code you basically need the following changes:

Lines like

Code (cpp) Select Expand

tgui::Checkbox::Ptr syncbox(gui);
basically have to be changed to

Code (cpp) Select Expand

tgui::Checkbox::Ptr syncbox = tgui::Checkbox::create();  // You could use "auto" as type here, to not write "Checkbox" twice
gui.add(syncbox);

In 0.6 I think you still had to have a theme to render something, since 0.7 there actually is a default White theme that gets used if you don't set any theme. I'll just assume you want to keep using the Black theme. You will have to change THEME_CONFIG_FILE to "data/themes/Black.txt" as that is where the new Black theme would be located.

For the Black theme you will have to create a Theme object somewhere. Assuming you only use a single theme you can set it as a default as well. The "theme" object has to remain alive, if the variable is destructed (e.g. when it goes out of scope) then the built-in White theme will automatically be used again.

Code (cpp) Select Expand

tgui::Theme theme{THEME_CONFIG_FILE};
tgui::Theme::setDefault(&theme);
If you have a default theme that you want to use then you can just remove lines like

Code (cpp) Select Expand

syncbox->load(THEME_CONFIG_FILE);
If you don't have a default theme, then you need to replace the lines with something like

Code (cpp) Select Expand

syncbox->setRenderer(theme.getRenderer("CheckBox"));

The biggest difference is probably going to be the callback code. TGUI 0.6 queued callbacks and let you get them later with pollCallback. (This code is so old that I had already forgotten that it used to work like that). Since TGUI 0.7 the callbacks are like interrupts, your callback function will be called immediately. You should definitely read the signal tutorial.
How you need to change the code depends on the structure of your code. If your code is really all in one big main function, then you should actually be able to port it without too much changes.

Code (cpp) Select Expand

knob1->bindCallback(tgui::Knob::ValueChanged);
knob1->setCallbackId(Knob_CALLBACK_ID + 1);
and

Code (cpp) Select Expand

case Knob_CALLBACK_ID + 1:
{
[...]
break;
}
would become

Code (cpp) Select Expand

knob1->connect("ValueChanged", [&]{
    [...]
});

Those are just the differences that I saw when scrolling to the code. It is possible that there are other differences, but the biggest changes happened in the way widgets are created and their events. The functions of the widgets themselves (e.g. setPosition, addItem, setSelectedItem, etc.) will mostly be compatible.

The MenuBar widget is a bit more complicated than most widgets. I would somehow need to provide an interface to set the menus and their items. I would also need to serialize the menus (including potential submenus) into a single string, preferable without newlines.

The serialization problem could easily be solved if I just use the same format that I currently use for saving a MenuBar to a text file and just replace the newlines with spaces, although maybe there are better alternatives.
The thing that will take more work is providing a form where you can change the properties without having the manually type in the serialized string by hand. The thing I have in mind is something similar to how items of a ListBox are set, but with a TreeView to display the menus. The ability to enable and disable any item complicates this a bit more.

I recently added ChatBox and TreeView widgets to the gui builder, but only because they could be added without a way to set their items at design time. For a menu bar, being able to set the menus at design time is more important so I really do need to provide a way to input the menus. Unfortunately I currently don't have the motivation to actually implement it, I haven't been able to get myself to work on any non-trivial features in TGUI lately.

The option is missing.

You actually just have to set the Height to a larger value than the Width. I'll put on my todo list that I should add a property for it in the gui builder to make it more intuitive, because someone else recently had the same problem with a Slider and I agree that it isn't obvious at all.

Also; If possible, it would be nice if we could set the angles of scrollbars, sliders, etc.

When rotating over an angle other than 90° there is no more obvious definition about where the top left position actually is. There are multiple ways the scrollbar could be positioned after e.g. a 45° turn. I've never seen diagonal scrollbar, is there a use case that you have in mind where you would need to rotate it over such a non-standard angle?

My need for std::bind is a bit more complex than this example

If you had tried a simple case first then maybe it could have saved you some time with trying different things .
After some debugging, trying to compile the code you described, I decided to just check the most basic code that you mentioned at the top. It didn't work either.

It turns out there is a good reason why it isn't in the 0.8 tutorial, it simply no longer works.
The reason it used to work was more of a side-effect of the way my internal code worked, it was never an intended feature to have (although I did document it in the tutorial after I found out about it). All parameters passed to the connect function were passed to std::bind inside the signal class. The getNum function being called at the moment func1 is called was a consequence of passing an std::bind argument as parameter to an std::bind call. In 0.8 I don't use std::bind anymore however. I've learned that lambdas are both faster and more powerful and saw no more use to rely on std::bind in my implementation.

The quick solution should have been to just surround everything with the std::bind that used to be inside the connect function...

Code (cpp) Select Expand

button_image->connect("MouseEntered", std::bind(&TitleMenuButton::ButtonFocused, this, std::ref(button_selected), std::ref(current_button), std::bind(get_button_function, current_button)));
... but that unfortunately doesn't work. My new signal system in 0.8 doesn't seem to like the argument being a bind expression (which acts really weird). (EDIT: Although I don't recommend doing it like this, I do consider this a bug. So I will try to change the code soon so that the above line does work.)

I would recommend just not using std::bind at all:

Code (cpp) Select Expand

button_image->connect("MouseEntered", [&,get_button_function]{ ButtonFocused(button_selected, current_button, get_button_function(current_button)); });

In the above line, the get_button_function is passed as a copy to the lambda because unlike the other parameters it is a local variable and thus a reference to it won't be valid anymore when the MouseEntered event occurs. The "&" makes sure the other parameters do get passed as a reference.

The color not being updated when disabling and enabling the widget has actually been fixed already. Try building the version from github: https://github.com/texus/TGUI

is there a way to change the menu item text?

This is currently not possible. You will have to remove the items and add them again (either all menus or just the menu in which an item needs to change by calling removeMenuItem for each item).
If you want to have spaces in front of all items and only have the star in front of one item then you need to update multiple items anyway and recreating the menu might not be such a bad solution.

If it were possible to change an individual item text, how would you want the API to look like?

Code (cpp) Select Expand

menuBar->setMenuItemText("menu", "menuItem2", "> menuItem2");
menuBar->setMenuItemText("menu", "> menuItem2", "menuItem2");
or

Code (cpp) Select Expand

menuBar->setMenuItemText("menu", 2, "> menuItem2"); // 2 being the index
menuBar->setMenuItemText("menu", 2, "menuItem2");

The first one looks nicer to me, but for the second one you don't need to care what the current text is to change it. On the other hand, the first one would be easier to extend to sub-menus.

Purely as information on how to improve the MenuBar in the far future, would you still need this feature if it were possible to display an image in front of menu items (either a unique image per item or just a single "selected" image that is used in front of any item that gets selected)? Or if there were optional checkboxes in front of items?