Messages

I'll have to look into that. Perhaps in the meantime you can use code like this and check if that works:

Code (cpp) Select Expand

void function(sf::RenderWindow& window, const sf::String& item)
{
    if (item == "Exit")
        mWindow.close();
}

mMenuBar->connect("MenuItemClicked", function, std::ref(mWindow));

Unfortunately my windows drive got corrupted a few days ago so it will take a few hours/days before I have everything up and running again to test that code and find out why it doesn't compile.

EDIT: Are you using the latest update of VS2015? You need at least update 2 to have full support for the connect function.

The function is called on any action, so you have to check it inside the callback function itself.
Which item you clicked is passed as optional argument to the function, so the callback function has to look like this:

Code (cpp) Select Expand

[&](const sf::String& item) {
    if (item == "Exit")
        mWindow.close();
}

I can't really answer that, you will have to try it yourself. But I don't immediately see a reason why it wouldn't work.

In case you still care, the MenuBar now has a setInvertedMenuDirection function in 0.8-dev.

In case you would still be interested, TextBox now has setCaretPosition, getCaretPosition and getLinesCount functions in TGUI 0.8-dev.

This issue has been fixed on the master branch on github. You can dowload the ZIP and build tgui yourself or wait several weeks/months until the release of TGUI 0.7.3.

It is not as optimized as TextBox, but it will be good enough now. If you go over a thousand characters you will again start seeing fps drops but that is not really a realistic case. Maybe one day I'll improve the code to track what the first and last displayed character is so that I can make the code run independent of the amount of characters, but nobody should have any performance problems anymore with the current implementation.

This is not something that I could easily fix. When it is disabled it no longer receives events so it doesn't know if the mouse moved during that period or not. When it is enabled again it isn't allowed to check if the mouse is on top it or not because it might be possible that the mouse is on top of it while there is another widget in front of it. So the only way to fix this (without changing the fact that disabled widgets don't receive events) would be to send a signal to the root container every time you enable a widget to resend the last mouse event so that the widget could potentially update its state. That is a lot of work to to solve such a minor issue.

The issue may be bigger for you if you have no separate disabled image. If you use the themes that come with tgui then a disabled button looks identical to a normal button and you will thus see no difference when the button is re-enabled. If you would have a disabled image then it would change from disabled to normal instead of from disabled to hover which would be less problematic than seeing no visual change at all. So maybe you could add a "TextureDisabled" propery to the theme file that you are using.

Adding images for the disabled state in the Black theme is already on the todo list but I just don't have enough time to work on tgui right now and there are so many other things to do as well.

TGUI has the DroidSerif-Regular font build-in so that you don't need to load any external files to get some text on the screen. Adding the font in the library makes the library file bigger which is why I chose this small font.
The DejaVuSans font is still there from before there was a build-in font, I just never removed it.

You need to have a font that supports these symbols, the default font that ships with tgui probably doesn't have them. You can use the setFont function on the widget or the gui to change which font you use.

TextBox is highly optimized to support many characters.
In tgui 0.5 there was indeed a similar issue where selecting text in TextBox with more than 500 characters would freeze the program for a moment (getting less than 1 fps), but this issue was fixed when rewriting the class in 0.6. It should handle up to 100 000 characters fine now.

It seems to be because of the amount of characters and unrelated to the scrolling.
I need more than 100 characters to have a very noticable framedrop here which is more than you normally put in it, but it would of course be better if there wouldn't be an issue with the amount of characters.

Looking over the code it didn't take me long to find the issue: there is a function that takes the mouse position as input and returns the character in the text where the mouse is which is written in a very naive and unoptimized way.

It won't be fixed anywhere soon though. While I was rewriting text handling in 0.8-dev I also came across this part of the code and wanted to optimize it. It turned out that I didn't even fully understand how the code works anymore and eventually I decided to leave it like it currently is.

The best I can do right now is put it on the todo list and when it ever gets optimized you could just update to the new patch release and the problem would be gone.

Since it is possible to have every texture in a separate file, tgui treats textures as separate. So there is no optimization on the amount of draw calls at all. A button will do 2 draws (background and text) and e.g. a list box will do one for the backround, one for each visible line and several for the scrollbar (arrows, background and thumb).
I know you can have hundreds or even a few thousands of widgets while still having a good framerate on a low end pc, but that is of course with just the gui and nothing else being executed while you of course will want most of the time spend in your own code. So you will have to experiment a bit yourself and see how much drawing widgets affects the performance. Just keep in mind that performance was never a main goal of tgui, some parts will be better optimized than others.

As far as I know the UI that it was based on is free to use for any purpose. I don't think you have to worry about putting it seperately in your license, I guess it is similar to including TGUI and SFML: these parts are still under their original license while your project as a whole is GPL.

I just mean printing the mouse position every time you get a mouse move event and see if you get duplicates.

I've noticed in the past that if I move my mouse very slowly then I could get multiple MouseMoved events with the same mouse position (after a few events it does move a pixel of course). How many events are generated may depends on the hardware. So it would be interesting for me to know if when you move your mouse fast, slowly or even not moving it at all if the mouse coordinate in the MouseMoved is sometimes the same multiple events in a row. If there are several duplicates then it might be worth only handling the changes in my handleEvent function and drop duplicates.

What I could do is store the last mouse position and only handle the event when the position changed. I think that should fix the problem. Could you check if the mouse position remains the same during these phantom movements?

It will make my code a bit more complex since I will also have to keep track of what the handleEvent function returned during the last mouse event, but it could be an optimization if the mouse generates a lot of mouse events.

The timers are updated when drawing the gui. I can't see any case where they would blink. You shouldn't be able to blink faster than timeToDisplay anyway (and that is when moving the mouse which you aren't doing).
So maybe you can try setting the timeToDisplay to a different value (e.g. 2 seconds) and see if it affects the blinking.

Maybe you can also add the following right in front of the handleEvent call to check that you aren't getting events without knowing it:

Code (cpp) Select Expand

std::cout << ((event.type == sf::Event::MouseMoved) || (event.type == sf::Event::MouseButtonPressed)
|| (event.type == sf::Event::MouseButtonReleased) || (event.type == sf::Event::MouseWheelMoved)) << std::endl;

I originally splitting them up to not have too much functions in the widgets (in some widgets there are more widgets for how the widget looks compared to functions for the logic part). Most of these renderer functions will probably never be used, especially since people will more likely load themes than manipulate a single widget renderer manually.

Just splitting it up like I did in tgui 0.7 lead to some bad code (both classes had to be friends to each other and were constantly accessing variables from each other). When I was considering reverting back I got into a discussion about it here: https://github.com/texus/TGUI/issues/45 (there is more text about the renderers than about the original topic).

For 0.8 I wanted the renderer to be independent of the widget itself. That discussion on github gave me some ideas on how to do it but what I have now in 0.8-dev is still very different from what was discussed there, but at least they are a lot less dependent on each other. The renderer is now independent of the widget, but at the cost of performance overhead and a widget that still contains almost all the code. The architecture isn't as good as I had hoped when I started splitting the class up but it is the best I can do for now. There are still some minor limitations (e.g. you can't change a property on the theme itself, you have to change the renderer of one button to change the way all the other buttons connected to that theme are drawn), but those are things that I still hope to improve before releasing 0.8 (which probably won't happen in the next 1-2 years anyway).

As soon as you move the mouse the tooltip will vanish (no matter if you stay on the same widget or not).
The tool tip will only be added after timeToDisplay has passed without a single mouse event (on every mouse event the timer is reset).

I can't think of a reason why that would happen without mouse events.

Once visible, it should only be removed again when the handleEvent function is called where this case is true:

Code (cpp) Select Expand

if ((event.type == sf::Event::MouseMoved) || (event.type == sf::Event::MouseButtonPressed)
|| (event.type == sf::Event::MouseButtonReleased) || (event.type == sf::Event::MouseWheelMoved))

The goal of the renderers was to keep the logic code of a widget and the way it is displayed separate making the code a bit more modular.

It didn't entirely work out like planned. In 0.7 the rendering system was written and there was one renderer instance per widget. So basically the only use of the renderers was keeping the widget interface smaller (to change how the widget works there are functions that you call as widget->abc() while to change how the widget looks you call widget->getRenderer()->xyz()).

In 0.8-dev it got rewritten and the renderers are now shared between widgets. The renderers just store how you want the widget to look while the widget still does everything including drawing itself.

So there are 2 things you need to know about how they work:
1) They just contain the setters for when you want to change something. To change e.g. the text color of a button you can do button->getRenderer()->setTextColor(sf::Color::Red);
2) In 0.8-dev the renderers are shared between widgets. If you got the renderer from a theme, you can change how all the widgets look with a single function call to the renderer.

The RendererDefines is purely for internal use, they avoid too much copy-pasting in the code and the WidgetRenderer is the base class for all renderer classes, it contains the functions that you can call on any renderer.

I have found the issue but it will have to be fixed in all affected widgets individually.

I don't have time right now to fix all widgets but I have already fixed it in TextBox and several other widgets in a seperate branch: https://github.com/texus/TGUI/tree/WIP-clipping-fix
If you download and build that version than the problem you have with TextBox should be solved.

I'll make sure to have a fix for all widgets before I release 0.7.2 (which is planned to be released when SFML 2.5 is released), but it will likely be fixed much earlier (within the next week).

I have been able to reproduce this, the problem seems to be with the way I calculate the clipping so it will likely affect some other widgets as well. But I haven't found the exact cause yet.
It does seem like the issue got fixed in 0.8-dev already when refactoring the clipping code, so if I can figure out what got changed then I can put the fix in 0.7 as well.

There are a few ways to do this depending on the situation. Since you are talking about the main function I doubt you are using classes so I'll show an example with just a normal callback function. But for more complex situations it might be worth having the callback function in the same class as the code that needs it so that you can just access member variables instead of having to pass everything you need as parameters to the function. But here I will just pass the gui and the panel as parameters:

Code (cpp) Select Expand

void func(tgui::Gui& gui, tgui::Panel::Ptr panel, const std::string& item)
{
    if (item == "Debug")
        gui.add(panel);
}

menuBar->connect("MenuItemClicked", func, std::ref(gui), debugWindow);

Note that you pass 2 parameters to the connect function that are intended for the func callback function. When a menu item gets clicked, these parameters (a reference to the gui and the debug panel) will be passed as the first 2 parameters to func, while the remaining parameter (the string) will be provided by the gui and for menu bars will contain the item that you clicked on. Note that in order to pass a reference, you have to both use std::ref at the connect call and have the "&" when declaring func. If either is missing then it will still compile but you will copy the parameter instead of passing a reference. In this example a copy of debugWindow is made at the moment you call the connect function, this shouldn't be a problem since it is a pointer but if it would be a nullptr at the moment that you call the connect function and only assign a value later then the func still gets nullptr as parameter. So depending on where you initialize debugWindow you might also need to pass the panel pointer as a reference. I hope that the explanation makes some sense to you.

edit: I only saw that you removed your question after I finished writing my reply

You can find a tutorial about it here: https://tgui.eu/tutorials/v0.7/signals-introduction/

You basically no longer have a callback loop where you poll for callbacks but instead you call a certain function when something happens. You bind this function by calling the connect function.

Example:

Code (cpp) Select Expand

void f() { std::cout << "clicked on some menu item" << std::endl; }
menu->connect("MenuItemClicked", f);

In this case you probably want to know on which menu item you clicked, so you can use the following code (unless you use VS2013 in which case you need an alternative way involving the connectEx function)

Code (cpp) Select Expand

void f(std::string item) { std::cout << item << std::endl; } // will print e.g. "Exit"
menu->connect("MenuItemClicked", f);

or using a lambda function:

Code (cpp) Select Expand

menu->connect("MenuItemClicked", [](std::string item){ std::cout << item << std::endl; });

The issue with menu bar in a container is now fixed in 0.8-dev as well.

1) I only fixed it on 0.7, I'll apply the fix to 0.8 tomorrow
2) Panels have to be used as radio button group (when one radio button is checked then all other radio buttons with the same parent are unchecked). Adding a RadioButtonGroup class to make it easier is already on the todo list for 0.8 though.