Messages

The Tooltip widget has been added to v0.7-dev.

When using the built-in white theme, you only need to set the text.

Code Select Expand

button->getTooltip()->setText("Hello world");

Otherwise you must load the theme file first.

Code Select Expand

button->setTooltip(tgui::Tooltip::create("Black.conf"));

Edit:
But the downside of this news is that v0.7 is still far away from being released, so using v0.7-dev is not a great option unless it is just for testing, and I will not port the Tooltip widget to v0.6.

You can add the following to the Button section in Black.conf

Code Select Expand

FocusedImage_L    = "Black.png" (  0, 175,  50, 50)
FocusedImage_M    = "Black.png" ( 50, 175, 100, 50)
FocusedImage_R    = "Black.png" (150, 175,  50, 50)

You can use the tab key in the program to change the focused widget (in case you have more buttons) and you may want to call button->focus() to have it focused when the program starts.
Just know that changing the focus with the tab key doesn't tend to work very well when stuff like child windows or panels are involved.

The ReturnKeyPressed callback is only triggered when the button is focused while you press the return key. This was done so that buttons can be "pressed" by selecting them and using space or return key instead of only when clicking on them with the mouse.

But the Black theme provides no focus state for the button (the image contains it, but it is not loaded by Black.conf) so this part does not work with the default Black theme. The Black theme is meant to only be used with a mouse (same for White and BabyBlue themes).

The focusing part isn't really advanced enough to be decently used, thats why it is disabled by default.

No, not yet. I will add them on my todo list for v0.7.

I guess I will end up implementing it like this:

Code Select Expand

auto tooltip = tgui::ToolTip::create("Black.conf");
tooltip->setText("Hello world");
picture->setToolTipText(tooltip);

For normal widgets the last line would have been gui.add(widget), but since tooltips are not supposed to be in the gui but connected to a widget I will have to give every widget such a setToolTipText function.


I always delayed tool tips for a different reason as well. Having custom tool tips is one thing, but having them integrate nicely with the gui is another. With just a simple setText function it would seem impossible to make the tooltip display e.g. the item of the listbox below your mouse.
But I learned some really cool c++11 stuff yesterday. So if I would add a function that returns the item below the mouse then you could type:

Code Select Expand

tooltip->setText(std::bind(&tgui::ListBox::getHoveredItem, listBox));

So that solves the limitation that I always thought I would have.

The v0.7-dev branch is now public here: https://github.com/texus/TGUI/tree/v0.7-dev

The TextBox is fully rewritten there.

Picture is actually an exception. Unlike other widgets it is loaded with just a single image.
So I have quickly added this to v0.6 for Picture instead of delaying this to v0.7 where it will be possible for all widgets.

You can download the latest TGUI v0.6 version from github (will be released as v0.6.6 in 3 weeks). Then you will be able to write the following code:

Code Select Expand

sf::Texture texture;
texture.loadFromFile("ThinkLinux.jpg");

tgui::Picture::Ptr picture(gui);
picture->loadFromTexture(texture);


There is currently no way to load widgets from memory.

This will be changed in v0.7. Picture will definitely support taking a reference to an existing sf::Texture.
The entire loading mechanism should probably be changed for loading the other widgets from memory: https://github.com/texus/TGUI/issues/27

But this is not something to be expected soon.

I think I understand what went wrong.

The SFML version provided in the precompiled TGUI libraries is newer (and more stable) than SFML 2.1.
Some changes have however been made to sfml concerning linking statically, which were made AFTER the release of sfml 2.1. When linking statically to the newer sfml versions you have to also link its dependencies.
More info: https://github.com/LaurentGomila/SFML/wiki/FAQ#build-link-static

Glad that you like it and got it working.

I do want to see if I can reproduce these opengl errors though. What is your compiler and sfml version?

Since the crash occurs in sfml, this is most likely a library incompatibility.

So make sure you check everything mentioned here: https://forum.tgui.eu/index.php/topic,216.msg1092.html#msg1092

I don't like using google drive anyway. I always have to look for the download button for a moment.

With dropbox the download button is big and in the center of your screen. Plus I figured out that if you make the url end with "?dl=1" then you don't even get to the dropbox page but the browser starts downloading it immediately when clicking the link. So I find that easier to share.

But I guess dropbox isn't perfect either. I happen to have 19GB of space on it, but I think you normally only have 2GB which might be a bit limiting.

This was indeed a bug in tgui. It was extremely hard to find though.

Although commenting out moveToFront prevented the crash in your case, it has absolutely no link with the mistake which was in the Container::remove function (which got called when you call messageBox->destroy()).

The crash should no longer occur u use the latest version https://github.com/texus/TGUI/commits/master.

This is exactly why it is a bad idea to use the PATH. The dlls should be next to your exe and not in some folder in the PATH variable.

But I'm glad you figured it out, and I'll try to remember that program.

If its compiled with mingw then you could perhaps send it to me (including the mingw dlls that you have to ship) so that I can test to see if it runs?
Executables created by visual studio require me to boot my windows to install redistributable packages, for which I don't have time now.

You need to be sure that the error that he is getting is exactly "TGUI error: Failed to open graphics/gui/Black.conf."
If its any other error then there might be another problem.

The file is just read with an ifstream. There is a difference between "failed to parse" and "failed to open" though.
But if the error is exactly "TGUI error: Failed to open Black.conf." then it just means that the std::ifstream::is_open returned false and thus the file really isn't in the location where it should be. The error tells exactly what it tried to open, if it just said Black.conf then it is supposed to be located in the folder from where the exe is being ran. Otherwise there will be a pathname too.

I would be surprised that it would fail to open when the file is there.
I can't see any situation where it would work on your pc and not one one from someone else unless you haven't distributed the file correctly (e.g. somewhere in your code it is loading the file from a different path than you expect).