TGUI: GUI library for SFML

[Laurent]

A compiled library is not supposed to be pushed to a repository. A better solution is to manage it externally, either by providing the needed information so that your project can find it (find_package if you use CMake) or by including it as a submodule of your repository and recompiling it together with your project.

[eXpl0it3r]

Also debug libraries can become quite huge, so that's not really surprising.

[jill]

Hello. How to write the menubar callback ?

tgui::MenuBar::Ptr bar = std::make_shared<tgui::MenuBar>();
// add some menus and menu items
...
bar->connect("menuItemClicked", [](const std::string & item, int id) {
           // some proccessing
}, "Edit", 1);
 

Why pressing any menu item will trigger the lambda callback, how to write the menu item callback?

[texus]

The menuItemClicked is called for every menu item you click. By providing extra "Edit" and 1 parameters you are binding these parameters to the lambda function so that any function call will have these parameters. Unless you are using VS2013 (in which case you should check the connectEx function), you can leave one string parameter unbound which will then contain the item you clicked:

tgui::MenuBar::Ptr bar = std::make_shared<tgui::MenuBar>();
bar->addMenu("Edit");
bar->addMenuItem("Edit", "Copy");
bar->addMenuItem("Edit", "Paste");
//...
bar->connect("menuItemClicked", [](const std::string & item) {
   if (item == "Copy") {
        // some proccessing
    }
    else if (item == "Paste") {
        // some other proccessing
    }
});

[jill]

Yes, it works fine on FreeBSD. I love tgui. 

[jill]

From 0.6 to 0.7, the tgui api changes from callback to signal, so does it will be changed in the future release? Is it valued to pay more attention to the signal?

[texus]

I'm definately not going back to the old callback system.
All TGUI 0.7.x patch releases keep a compatible api with 0.7.0 so they will all use the Signal class.
You shouldn't worry about 0.8 because it is still years away from being released, but the code in 0.8 will likely be very similar to the signal code in 0.7.

[jill]

Hello, Texus.
There is a question in my heart for some times.

button->connect("pressed", print, std::bind(getValue));
 

I think this is too loose. I wish it be more strict.

 See this will work too:

button->connect("pressed", print, std::bind(getValue)());
 

auto f = std::bind(getValue);
f is a function.
f() is a value.

We should pass a value as a parameter to print, right? Both will work. But the second one is more strict which is what I wish.

[Ruckamongus]

The connect function is given by:

template <typename Func, typename... Args>
unsigned int tgui::SignalWidgetBase::connect(const std::string& signalNames, Func func, Args... args)

I'm not sure what the purpose of disallowing a function as an argument would gain? If you need it for safety you could edit the source and ensure that "args" isn't a function (std::enable_if<> and std::is_function<>) maybe though.

[texus]

Both forms should be allowed because they do different things.

When a value is passed, a copy of the value is stored and later passed as parameter. You could use std::ref to pass a reference to the variable though.

When the result of an std::bind is passed, the bound function will be called when the callback occurs.

So the first line will call getValue() each time the button is pressed.
The second line calls getValue() and passes the value to the connect function as a constant. No matter what getValue() would returns when the button is pressed (it not being called), the parameter of your callback function will be a constant in this case: the value it had when the connect function was called.
So you will likely want to use the first one.

[jill]

Thanks to Ruckamongus and Texus,  Right, std::bind(getValue) is a functional type passed to the signal function, and itself need another parameter which is provided by system, such as the slider changes and then click the button.

[0x00]

Many thanks for TGUI it really simple and useful UI system)
I have small question what version will be implemented TGUI RichText and RichEditBox? Wanna see in 0.8V RichText 

[texus]

RichEditBox or RichTextBox is not planned. They will probably only be added if someone else writes and contributes them.

RichText will be added in the future but it will probably take more than a year before I will look at it.
In case you didn't know there is code available for such a widget (RichTextLabel.hpp) which is based on https://bitbucket.org/jacobalbano/sfml-richtext. You have to include "TGUI/Widgets/devel/RichTextLabel.hpp" in your code to use it. It will have to be rewritten before I accept it as part of the gui though, it hasn't been tested for a while and part of its code doesn't fit with the rest of the gui.

[texus]

There is now a C binding and a .Net binding available for TGUI 0.8-dev.

Note that these bindings are still experimental (they have only briefly been tested) and TGUI 0.8 itself is still in an early stage of development.

[eXpl0it3r]

Awesome news! Keep it!

Btw. do you use TGUI yourself in some (bigger) project?