Messages

I'm a little afraid of retro compatibility between 0.8 and 0.9,  do you think we'll have to re-write a lot or is it can be used as is?

There have been quite some changes. A large part of the API remained the same, but e.g. connecting callbacks are different and some parameter types were changed. Updating should be possible within a couple hours, but it might be annoying work. If you are loading all your widgets from a text file then I can't recommend updating as there is no way to import 0.8 files in 0.9 (although if you don't mind boring work they can easily be updated manually in less than a day, I had to update the screens in the gui builder itself by hand too).

I'm impressed on how you handle feedbacks

I definitely try to work on stuff that people suggest, but you also need to have some luck to get a feature implemented. Things get asked for often without them being implemented (usually due to lack of time). This wasn't the first time (nor the second time...) this functionality was requested, I even knew I needed it when I originally added support to resize the child windows. So it was something that I have known to be a limitation for quite some time and I had already given it a lot of thought (not necessarily in exact implementation, but about what challenges there would be and which ways I shouldn't implement it). That combined with the fact that I was almost finished with a large change for 0.9 and was looking for the next thing to do caused this to appear high on the todo list. I just finished what I was working on yesterday (reorganising some code, making widgets even less dependent on SFML), so I'm actually planning on looking into the cursor thing this weekend.

I've been thinking about how to design it, and this is what I came up with so far. Note that since this is not a small change, it would be added to 0.9-dev, not in the 0.8 branch.

I will only support cursors that are available on all platforms for now, but I will add the Linux implementation of the resize arrows in my own code so that resize cursors are also supported on all platforms.

There would be a Cursor class where you can change the look of each cursor type:

Code (cpp) Select Expand


class Cursor
{
public:
    enum class Type
    {
        Arrow,                  //!< Arrow cursor (default)
        Text,                   //!< I-beam, cursor when hovering over a text field
        Hand,                   //!< Pointing hand cursor
        SizeLeft,               //!< Left arrow on Linux, horizontal double arrow cursor on Windows and macOS
        SizeRight,              //!< Right arrow on Linux, horizontal double arrow cursor on Windows and macOS
        SizeTop,                //!< Up arrow on Linux, vertical double arrow cursor on Windows and macOS
        SizeBottom,             //!< Down arrow on Linux, vertical double arrow cursor on Windows and macOS
        SizeTopLeft             //!< Top-left arrow on Linux, double arrow cursor going from top-left to bottom-right on Windows and macOS
        SizeBottomRight,        //!< Bottom-right arrow on Linux, double arrow cursor going from top-left to bottom-right on Windows and
        SizeBottomLeft,         //!< Bottom-left arrow on Linux, double arrow cursor going from bottom-left to top-right on Windows and macOS
        SizeTopRight,           //!< Top-right arrow on Linux, double arrow cursor going from bottom-left to top-right on Windows and macOS
        Cross,                  //!< Crosshair cursor
        Help,                   //!< Help cursor
        NotAllowed              //!< Action not allowed cursor
    }

    // Changes cursor until restoreOverrideCursor() is called, calls to setOverrideCursor stack (design taken from Qt)
    void setOverrideCursor(Type);
   
    // Undo last setOverrideCursor call
    void restoreOverrideCursor();

    // Changes how the mouse cursor of a specific type should look like. By default the system cursors are used,
    // but you can use this function if you want to change them to bitmaps.
    void setCursorLook(Type, sf::Cursor);

    // Function called by TGUI to change the cursor. If you call this yourself then the cursor will change, but it will
    // revert back when you move the mouse (since TGUI changes it)
    void setCursor(Type);
}

Each widget would have a setMouseCursor function where you tell it to change the mouse cursor on hover. The downside of this approach is that it has to be called on each widget separately, but it does provide full control over which widgets should change the cursor. It also allows e.g. setting a NotAllowed cursor on a disabled button, so you are not limited to only a hand icon for buttons.

Code (cpp) Select Expand

editBox->setMouseCursor(tgui::Cursor::Text);

For child windows (the part that you are interested in), there would be a function to enable/disable the resize cursors. I think I'll enable the option by default, because you probably always want this for resizable windows.

Code (cpp) Select Expand

childWindow->enableResizeMouseCursors(true);

It's currently not possible.

I once looked into it, but one issue was that linux doesn't support the double arrow (https://github.com/SFML/SFML/blob/master/include/SFML/Window/Cursor.hpp#L65-L66).
Linux uses a single arrows (so it has a different arrow for each corner and window side), Windows only has double arrows and macOS supports both single or double arrows. Ideally you would be able to ask SFML for a single arrows and have it fall back to the double arrow on windows, but SFML only supports the double arrows (and thus can't display the native linux arrows).

Another (larger) issue, is that I don't know how to design the API for it. Some might want the system cursors (e.g. likely when you want a cursor on top of an edit box), while others might want a custom cursor (which is also possible with SFML). The API should somehow provide a callback that the cursor should be changed, but in what cases should it be send? Resizable child windows are the most obvious, but I imagine there might also be interest in an edit icon when hovering EditBox or TextBox. Some people might also want a hand icon when hovering buttons, but I imagine other won't want that at all, and I'm not sure how to handle that difference properly.
Maybe I should have a look at how other GUIs handle this.

It's currently not possible.
Are you talking about double-clicking the header or knowing the column when double clicking an item (I'm assuming the second one)?
What use case do you have that requires knowing which column was clicked?

CTGUI was written to build the TGUI.Net binding, CTGUI wasn't really intended to be used directly. This is why the library lacks documentation and doesn't has a separate forum section.
You can use the library, you just shouldn't expect it to be as user-friendly as TGUI or TGUI.Net.

The problem seems to be that MenuItemClicked isn't of type SignalItem in c++ (and you thus can't use tguiWidget_connectItemSelected), but it has type SignalItemHierarchy.
The SignalItemHierarchy supports functions with 3 sets of parameters:
- No parameters at all (use tguiWidget_connect in CTGUI for this)
- A string parameter with the menu item that was clicked (use tguiWidget_connectString in CTGUI for this)
- A vector of strings with the hierarchy of the clicked menu item (if you don't have submenus then it contains 2 items: the menu and the menu item). This is apparently not available in CTGUI and TGUI.Net.

Although not related to your issue, is there a reason why you are using an older CTGUI version? The last tagged version seems to be 0.8.6, but the CTGUI master branch itself should actually be up-to-date with 0.8.7

tguiWidget_connectItemSelected returns 0 when it fails.
Could you check what tgui_getLastError() returns (the function is defined in Global.h) after calling tguiWidget_connectItemSelected ?

Also, what TGUI (and CTGUI) version are you using?

The mouseNoLongerDown isn't called anywhere inside TGUI (based on a quick word-search through the codebase), so I would think it is called from somewhere in your code. Otherwise maybe you have TGUI headers installed somewhere that don't match the library version?

You could add the TGUI_REMOVE_DEPRECATED_CODE define in your code (either project-wise or as a define before including TGUI.hpp). That will completely remove the function, any place that tries to call it will then give a compile error instead of a warning.

I'm not sure what could cause the OS to crash, maybe it goes out of memory? Are you trying to compile with multiple threads? Compiling with only one thread would reduce the memory usage, if this would be the problem.

Are you including TGUI.hpp or are you including Signal.hpp directly? If you don't include TGUI.hpp then you must also include SignalImpl.hpp

The problem is that _test() is a member function.
Unlike a free function (a function that isn't part of a class), a member function needs to know what object it is called on. If you access member variables or call other member functions then the code needs to know on which object it needs access these members (since you may create multiple Ch_window objects).

Although you don't write any parameters, the c++ compiler will generate a function that is equivalent to the following:

Code (cpp) Select Expand

void _test(Ch_window* this);

That is where the "this" object comes from that you can use within a class, behind the scenes it is a parameter passed to all your member functions.
So the function does have a parameter, which is what the connect call is complaining about (it doesn't know what value it has to pass to your this pointer).

Since TGUI needs to know on which object to call the _test function, you have to give it a pointer to the object. Since you are calling the connect function inside a member function of Ch_window and you obviously want to call the _test function on the same object, the pointer to the object is literally your "this" value. You also have to change the function name for it to work properly:

Code (cpp) Select Expand

channels->connect("SizeChanged", &Ch_window::_test, this);

Alternatively, you can use a lambda function, which is similar to what TGUI will internally do when you write the above:

Code (cpp) Select Expand

channels->connect("SizeChanged", [this]{ _test(); });

I see now what the problem was. It's hard to help with how you should pass data to different places because there is a lot of freedom in how to do it exactly without there always being a best way. For the simple case that you have here, returning the value like you are doing is probably the best option, but I'll provide some alternatives that you could keep in mind if you face a similar problem later.

I said earlier that tgui::Canvas::Ptr is a simple pointer and thus copying it isn't a problem. If it would have been a large object then returning it might not have been a good option, passing it by reference would have been better. In some cases you can still return a large object in such a way that it is moved instead of copied, but until you fully understand move semantics it might be a good idea to always assume that a copy would take place and pass large objects by reference parameter.

Code (cpp) Select Expand

tgui::Canvas::Ptr canvas;
channels_window(window, gui, canvas);
void channels_window(sf::RenderWindow &window, tgui::Gui& gui, tgui::Canvas::Ptr& canvas)
{
    canvas = tgui::Canvas::create();
    // ...
}
Design wise it might be better to call "tgui::Canvas::create()" before calling the function, but this example is to illustrate that you can pass an uninitialized object into the function which will initialize it.

Another alternative is to use a class member. It channel_sorting and channels_window wouldn't be free functions but instead were part of the same class then you could simply give that class a tgui::Canvas::Ptr member that you initialize in channels_window and use in channel_sorting. There is no need for passing parameters and return values in such case.

Yet another alternative would be to store the tgui::Canvas::Ptr inside the Channel class itself. This might not be a very good option here because you could have many channels and you would unnecessarily be making each channel class a few bytes larger, but it would also be an option in which you wouldn't need to pass the canvas in channel_sorting and draw_channel.

If you e.g. need sf::RenderWindow, tgui::Gui and tgui::Canvas::Ptr in a lot of places then another option would even become to put those together into a class and pass an object of that class around by reference instead of passing them separately.

An alternative that is specific to TGUI widgets is letting the gui store the widget. You can pass a unique name as parameter to the add function that allows you to retrieve it later:

Code (cpp) Select Expand

gui.add(canvas, "MyCanvas");
tgui::Widget::Ptr widget = gui.get("MyCanvas"); // Get the widget back, but as a base class on which you can't call Canvas-specific function
tgui::Canvas::Ptr canvas = gui.get<tgui::Canvas>("MyCanvas"); // Get the widget back, casted to the right type (might crash if widget with name "MyCanvas" wasn't a tgui::Canvas)
So as long as you have access to the tgui::Gui object, you can get access to any widget that was added to it.

So as you can see there are tons of options to get the canvas in the right place (even more than the ones I wrote), but knowing which design fits your needs best comes with experience by just trying and learning which choices didn't work well. If you are unsure which design is better, the best design is most often the one that requires you to write as little code as possible  (while makes the code as readable and understandable as possible, i.e. not focusing on the line count).


Not really related, but I wouldn't use the "ch(x)" define. It makes the code harder to read. If you really need to shorten the line (e.g. if you need to write several lines containing "tab_Channel[address_channel[x]]") then it would be better to just make a reference to the object:

Code (cpp) Select Expand

auto& ch = tab_Channel[address_channel[x]];
ch->draw_channel(canvas,column*52,row*72);

I don't have much time now, so maybe if I have more time to read your post I will understand it better, but right now I'm not sure where your problem is exactly. So I'll just quickly comment on some of the things you said.

I know that i must use canva->display() in my main or in a fuction called in the main, but i don't know how to do as the compiler wants the canvas to be declared

What exactly is the error? Is there no canvas variable (because no such object is declared there), or doesn't it know tgui::Canvas (because you wouldn't be including TGUI.hpp)?

but if i use (tgui::Canvas::Ptr &canvas) as argument of the fuction, wich prevent copying the canvas, i can't use the function in the main

Then there is something wrong about the way you call it in your main function. You need to have a reference to an existing object, it won't work if you e.g. try to create a new canvas on the same line as your function call.
That being said, TGUI widgets are wrapped in pointers. Without the "&" you are only copying the pointer, which still points to the same canvas, the canvas never gets copied. Taking the argument by reference would only be marginally faster because the Ptr is a std::shared_ptr which has to count the amount of pointers to the object: if it is copied then it has to increment the counter, if you take it by reference then it doesn't. So don't worry about passing it by value, but if the code doesn't compile when you try to use a reference then there is something wrong.

Edit : I tried to declare
tgui::Canvas::Ptr canvas;

This is equivalent of code like this:

Code (cpp) Select Expand

int *p;
In the best case p would be a nullptr, in the worst case it points to a random memory address. This is why it crashes if you try to use it, you need to actually create the canvas (so that the pointer points to something):

Code (cpp) Select Expand

tgui::Canvas::Ptr canvas = tgui::Canvas::create();

It might help if you created a small demo application that would show the issue (just a main function with just a few functions next to it that would actually be runnable on my pc). Only being able to see some of the code means that I would have to make assumptions about how the rest looks. I know for example that you did something wrong in main, but I can't know what. So it's a bit disorienting to follow what is going on, and right now I don't have time to really try and figure it out.

we're really seeking every opportunity to refresh only what we need
we're trying to keep in mind every opportunity to optimize display

By coincidence I actually fixed an issue today related to this ability. If you were to only draw the screen after you received an event (to minimize the amount of times you need to redraw the screen) then the cursor in edit box would for example stop to blink. Since there was no way to know when the cursor appears and disappears, you would still need to regularly draw the gui even when not receiving events (and you would waste CPU usage as most of the frames nothing would change).

In the 0.8 branch on github, I just made a change that allows you to know when a widget requires the screen to be refreshed (the change was already made in 0.9-dev last week, but I just backported it now). You would need to first call the following to decouple updating time and drawing in TGUI:

Code (cpp) Select Expand

gui.setDrawingUpdatesTime(false);

Then every frame, update the time:

Code (cpp) Select Expand

bool screenNeedsUpdate = gui.updateTime();

The screenNeedsUpdate variable will become true when something changes in the gui. It almost always will return false, but when an edit box or text box is focused it will return true twice per second so that you can update the screen to show the blinking cursor without having to refresh the screen more than you have to. If you use the showWithEffect or hideWithEffect functions in widget then the update function will return true the whole time while the animation plays, so you would still want to limit the amount of frames being rendered some other way if you want to use those functions.

Using widestrings will require you to store the value in a std::wstring or sf::String immediately, so your code where you add it to the return of std::to_string won't compile.
You could use u8"\u20AC" if you want to store it in an std::string (but your code wouldn't work when compiling with c++20 or higher because that would return an std::u8string instead).
So the best option would probably be to put it in an sf::String immediately:

Code (cpp) Select Expand

sf::String str_annual_wages = std::to_string(drivers_vector[i]->contract->getAnnualWages()) + sf::String(L"\u20AC");

Unless you are an organization with more than 5 users, Visual Studio has a free community version.

Maybe you should try L"\u20AC".
Having unicode characters in your code can be tricky, because it will require the cpp files to have the right encoding (and your code thus won't compile if someone uses a different file encoding), so it might be better just to use the hex code instead.

I would just treat the Canvas as you previously treated the RenderWindow: change your draw_channel function to

Code (cpp) Select Expand

void Channel::draw_channel(tgui::Canvas::Ptr &canvas,uint16_t x,uint16_t y)
and replace "window.draw" with "canvas->draw" inside the function.

Pre-rendering to a RenderTexture first is going to be marginally slower since you would be doing an extra draw call. If you would use a RenderTexture then you would also have to create it somewhere. Creating it is a "slow" operation, so you wouldn't want to use a single RenderTexture for each Channel object. You would end up with a single RenderTexture that you create once and pass around everywhere in your code, but that is exactly what you would do when you just pass the Canvas everywhere (Canvas is nothing more than a widget containing a RenderTexture).

Making a sprite in the class is the same option as creating a RenderTexture. You can't draw things to a sprite and you can't draw a RenderTexture to the canvas, you need both the RenderTexture and Sprite to make a drawing buffer. The only way to use RenderTexture and Sprite is to create a RenderTexture, draw on that render texture, create a sprite from the texture and drawing the sprite to the canvas. But again, that is just doubling the effort as this is what Canvas already does (it creates a RenderTexture, lets you draw on it with the clear(), draw() and display() function, creates a sprite from the texture and later draws that sprite to the window).

Whether your object should contain a draw function so that it can draw itself, or whether you have the rendering code outside the object is a design decision that might depend on how the code is used. But you actually already made this design decision. When drawing to the RenderWindow, you chose to keep the drawing code inside the Channel object, so there is no reason why you would suddenly do it another way just because you need to render to a canvas.

There is no problem in double posting if it makes sense to do so. If you asked a question for which there was no answer yet then it might be better to edit than to make many posts (I don't really care about one post more or less though, it's fine as long as you don't create 5 in a row). In this case your original response didn't contain a question though. I considered this topic close after reading your response, and editing doesn't send me a notification, so I never found out that you had another question until you posted another reply.

The issues seem to originate from not fully understanding what sf::RenderTarget is.

target = test; will not work

One is an sf::VertexArray, the other is a sf::RenderTarget, those are 2 completely different things.
The RenderTarget is what you draw on, it is a common base class of both RenderTexture and RenderWindow.
The VertexArray is a drawable. It is something you can draw on top of a RenderTarget.
If you intended to draw the vertex array to the render target then it should have been "target.draw(test)".
If you just want to pass the "sf::VertexArray" as a reference then you might be over-complicating things, why not just make the parameter "sf::VertexArray&" instead of "sf::RenderTarget&"?

sf::RenderTarget *target; // not sure if i can declare the render target like this

You cannot create a RenderTarget object, it is an abstract class. You either have to create a RenderTexture or a RenderWindow.
By making it a pointer, you have a variable that is supposed to point to a RenderTexture or RenderWindow, but if you don't set a value for the pointer then it points to a random location in memory so trying to use it will just crash (in the best case scenario).

canva->draw(target); // if the target is retrieved, it should draw fine.

Lines like these should always be in the form of "RenderTarget.draw(Drawable)". The canvas is a RenderTarget-like type, so you can call draw on it, but "target" isn't a drawable, so it cannot be passed to the draw function.

What I think you want to do is this:

Code (cpp) Select Expand

void test_draw(sf::VertexArray& test)
{
    // Replace the contents of "test" (which was an empty vertex array until now) with a new vertex array that contains 4 points.
    // Alternatively, you could have written "test->setPrimitiveType(sf::Quads)" and "test->resize(4)".
    test = sf::VertexArray(sf::Quads, 4);

    test[0].position = sf::Vector2f(0, 0);
    test[1].position = sf::Vector2f(50, 0);
    test[2].position = sf::Vector2f(50, 70);
    test[3].position = sf::Vector2f(0, 70);
}

sf::VertexArray arr; // create an empty vertex array that will be initialized by test_draw
test_draw(arr);
canva->draw(arr);

Alternatively, you can just return the VertexArray as return value:

Code (cpp) Select Expand

sf::VertexArray test_draw()
{
    sf::VertexArray test(sf::Quads, 4);
    test[0].position = sf::Vector2f(0, 0);
    test[1].position = sf::Vector2f(50, 0);
    test[2].position = sf::Vector2f(50, 70);
    test[3].position = sf::Vector2f(0, 70);
    return test;
}

sf::VertexArray arr = test_draw();
canva->draw(arr);

The bindRight behavior is not a bug, I tested it here and having it move through the child window means you are using it wrong. If the scrollbar is added to the gui instead of to the child window then it will follow the child window around (although not at exactly the wanted pixel).

bindRight = bindLeft + bindWidth
So if you move the child window around then the left position of the window changes and thus the scrollbar will also move. But the position of the scrollbar is relative to that of the child window (since you added it to the child window), so it will moves twice (once with the child window and once because you change its position with the bind function).

Also, Bindright seems to want to bind the left side of the scrollbar on the right side of the window, wich position it out the window

would'nt bindRight just want to stick right side of the widget on left side of the childwindow ?

The position of widgets is always the top left position, so even if you use bindRight, it will position the left side of the widget on that location. The bindRight function wasn't meant for overlapping widgets, it was meant for widgets that are placed next to each other. This is why you still have to subtract the width of your scrollbar from the position to get it to the right place. In TGUI 0.9-dev there is a setOrigin function now, so you would be able to call setOrigin(1, 0) and then you no longer have to subtract the width (because the position given to the widget would be the top-right position instead of top-left).

i think that's what you're talking about with bindInnerWidth

Not really. Imagine you have a panel of size (100x100) and it has a border of 10 pixels width. The contents of that panel is only (80x80). In order to have a widget of width 20px on the right side of the panel, you must place it on left position 60. If you were to use bindSize()-20 then you would actually be placing it on position 80 (=100-20). There should be a bindInnerSize() function that returns 80 so that you can do bindInnerSize()-20.
The example that I gave uses a layout with the string "100%". This is internally translated to widget->getInnerSize() and not widget->getSize(), which is why it worked. But there currently isn't a bind function to achieve the same thing, you currently have to create the layout using a string to get the wanted behavior.

ChildWindow behaves a bit differently in TGUI 0.8, it's inner size and size are the same thing, the borders and title bar are drawn outside of its size. Since this is inconsistent with the other widgets, this was changed in 0.9-dev where there is a difference between size and inner size now.

Btw, your email provider has been blocking more than just my forum email yesterday. Before I replied on facebook I had actually send you an email, but today I received it back as undelivered. As I said in that email (which I've quoted below), free.fr was blocking the messages based on ip address (at least that was what the error claimed). Messages sent using my mail client are however send using a completely different mail provider. So either it lies in its error message and just really dislikes the "tgui.eu" domain name, or they had temporarily blacklisted a lot of ip addresses.

It looks like free.fr is currently blocking ip addresses from sendgrid.com (which is where my forum emails are send from).
Sendgrid has been retrying to send the message every few minutes but it always gets a 451 error back.

I've activated you on the forum manually, you should be able to login now.

Code like that exists, you just need to make the "f" a capital letter (moveToFront instead of moveTofront).

If you don't need to call any function specific to MenuBar then you can skip the cast to MenuBar and have code that works for any type of widget:

Code (cpp) Select Expand

tgui::Widget::Ptr widget = gui->get("MenuBar");
widget->moveToFront();

The bindRight behavior sounds like a bug. Which widgets are parents to each other? Is the container inside the child window? Is the scrollbar added to the container, to the child window or to the gui?

The bindRight function was intended for sibling widgets that needed to be placed next to each other. Since it looks like you want the scrollbar on top of the container, maybe you should just add the scrollbar to the container and call

Code (cpp) Select Expand

scrollbar->setPosition({"100% - width", 0})

With bind functions this would be equivalent to the following, but note that you can't use this code yet as I just realized there is no bindInnerWidth function (it's sometimes equivalent to bindWidth, but bindWidth won't work correctly if your container has borders and padding).

Code (cpp) Select Expand

scrollbar->setPosition({bindInnerWidth(container) + bindWidth(scrollbar), 0})

If the scrollbar really has to be part of the container then you could consider using ScrollablePanel instead of creating a scrollbar manually.

You would have to use the Canvas widget for this.

The canvas acts like a RenderTexture (it's actually just a wrapper around a RenderTexture), so you use the clear(), draw() and display() functions on it to draw your SFML stuff on the canvas.
Since the canvas is a tgui widget, you can add it to the child window and it will display the last thing you rendered to it.
You only need to update the canvas when the SFML rendering changes, so if what you render is static then you don't have to redraw to the canvas every frame.

If a RichLabel would exist then you would easily be able to build chat box functionality on top of that widget and you would have freedom as to how each line looks. When I created the ChatBox I knew that a RichLabel wasn't going to be added soon (it was too much work), so I ended up writing the ChatBox widget to provide a minimal support for such use cases. Years have passed since then and the situation hasn't really improved: ChatBox is still the only widget with multiple colored texts and RichLabel still isn't expected anywhere soon.

Although adapting the ChatBox to display the name and text in different colors would be easier than implementing a real RichLabel class (that can change its color arbitrarily in the text), it does have similar difficulties. Single lines of texts are easy to render, but to use 2 colors you need to draw each line using up to 3 text objects which have to be carefully positioned (one for the name, one for the remainder of the line and one for other rows if the text doesn't fit on a same row).
This kind of code already exists in TextBox of course (which draws the text in up to 5 parts when multiple lines are selected), but TextBox is one of the most complex classes for a reason.

1) No, the line spacing is taken from the font. The distance between 2 lines could be controlled by TGUI code, but the distance between two rows on the same line is controlled by SFML. So you will have to use a different font.

When the renderers are changed to no longer use SFML code then this would become possible, but even if this happens then it would still require a rewrite in some parts of the code, so there won't be a fix for this soon.

2) No, ChatBox is read-only. What you are asking for is essentially a RichTextBox, and that widget shouldn't be expected anywhere in the near future (unless someone would contribute it).

Bonus) To remove the background you can call the following:

Code (cpp) Select Expand

chatBox->getRenderer()->setTextureBackground({});

Officially that currently isn't supported.
You could get it to work by faking a mouse event though:

Code (cpp) Select Expand

label->connect("MouseEntered", [=]{ checkBox->mouseMoved(checkBox->getPosition()); });
label->connect("MouseLeft", [=]{ checkBox->mouseNoLongerOnWidget(); });

That should be easily solvable by adding something like this:

Code (cpp) Select Expand

label->connect("clicked", [=]{ checkBox->setChecked(!checkBox->isChecked()); });

I'll add it to the todo list, but you could just replace the text with an actual Label widget for now.