Messages

It seems like this bug has already been fixed in the latest version, you can download it from github. You have to build it yourself with CMake.

You made me realize that the latest version on my download page is v0.7-alpha2. I will add a link to the source code of the latest snapshot as well, because there have already been quite some bug fixes.

Thanks for reporting. The fix has been made in the latest version that you can download from github.

A gui is bound to a certain window, if you don't pass the window in the constructor then you have to call gui.setWindow(window) once from somewhere else.

The best place to store the gui is probably where you store your window. Without a gui you would need the window in all of these stages anyway, now you just need both the window and the gui (they can be in some struct of data that has to be shared between all these places). So why can't you pass such a struct as argument instead of only the sfml window?

Yeah, that is correct.
I had to test myself what std::ref would do when the function itself doesn't take a reference as parameter but it does indeed passes the new value to the function.
But I guess you might have figured that out yourself by now.

Since I read your reply before the edit I only saw the edited version by chance. If you want to ask a new question it is better to add a new reply than to edit the post, that way I will get a new mail so I can't miss it.

1) You can call editBox->setNumbersOnly() to disallow text in it, but there is currently no way to limit the edit box to integers only (e.g. the following can be written in a numbers only edit box: "-1.235e6"). There are a lot of different uses for limiting characters (some would want only positive integers, others would want floats but without the optional 'e' behind it, ...) and I have not yet found a way to provide a proper way to allow all these possibilities.

2) An edit box is a single line of text without newlines, a text box is a multi-lined text field.

The code should work fine. In the code in your post you did use robot_face as widget while you called connect on robot_pic, but if they are called on the same object then it works here. If that was just a mistake in your post and not in your code then you might want to create a minimal code that shows the issue so that I can reproduce it here.

is there a way to make all tabs the same, fixed width, regardless of the text width?

It is planned before the final release of v0.7, but you shoudn't expect it soon: https://github.com/texus/TGUI/issues/42

How do I retrieve a pointer to a listbox (or any other widget) using get?

You could cast the returned value yourself with std::static_pointer_cast or std::dynamic_pointer_cast, but there is a templated get function which will do the static cast for you:

Code (cpp) Select Expand

tgui::ListBox::Ptr list_box_ptr = gui->get<tgui::ListBox>("List Box");

Another thing, how do I work with tabs? There's nothing about them in the tutorial.

Code (cpp) Select Expand

tgui::Tab::Ptr tab = std::make_shared<tgui::Tab>();
tab->add("First");
tab->add("Second");
tab->add("Third");
gui.add(tab);

Is there some sample code anywhere, with basic usage of each widget? That would ease the use of the library a lot.

I simply do not have enough time to write tutorials or example codes for everything. The only thing you can do to learn how a widget works right now is to check its functions in the documentation. (e.g. for Tab: https://tgui.eu/documentation/v0.7/classtgui_1_1Tab.html#pub-methods)

Focusing a disabled widget now no longer works with the latest github version.

Indeed, that shouldn't happen.
I only tried it with clicking on the widget and by using the tab key, I didn't try with calling the focus function manually before.
I'll fix this later today or tomorrow so that the edit box (and other widgets) don't get focused.

I'm not sure what you are asking exactly, but disabled widgets cannot be focused.

I can only think of one reason why this would happen, are you reusing the same tgui::Picture::Ptr in multiple places? Because every widget can only have one parent i.e. you can't add the same picture to multiple panels. You need to copy it if you want to use it somewhere else:

Code (cpp) Select Expand

tgui::Picture::Ptr pic1 = std::make_shared<tgui::Picture>("Image.png");
tgui::Picture::Ptr pic2 = tgui::Picture::copy(pic1);

If that is not the issue then you should show a minimal code example.

The idea of the current code was that you can use either a dot or a comma symbol to use for the decimal point. But things like spaces or more dots or more commas to make the text more readable are not supported.

I am aware that there is currently not enough control on which values are supported. When some people want numeric input they don't want to allow having negative numbers or only want whole numbers. In some cases "-5.26E-4" would be allowed, but when e.g. asking for the width of the window that value makes little sense.

I'm not sure if what you wrote would ever be supported though, because what if you write "1.000"? A lot of people will see that as 1 instead of 1000. It all depends on where you live.

So I will have to add something in the future to allow more options on how the string can look. But right now the only thing you can do to make edit box act like you want is not putting it into numbers only mode and binding the TextChanged signal. In the callback function you would remove unaccepted characters and you have full control over which characters can occur where.

It seems like button assumed that on mouse release you would be back in hover state (which makes some sense since internally tgui can only call that function when the mouse is effectively on top of the button). Other widgets don't seem to have this problem. Code on github has been updated to make it go back to normal state when the mouse is not on top of the button.

What do you mean by just replying "accessibly"?

TGUI does not respond to the right mouse button (or the middle mouse button). You would have to check the sfml event and check if the mouse is on top of something yourself if you really need it.

This was caused by an optimization that was made before label supported a background color. The draw function literally started with this:

Code (cpp) Select Expand

if (m_text.getString().isEmpty())
    return;

Fixed on github.

Did you give the label a size? If you don't call setSize it will auto-size to be as large as the text, if there is no text then there will be no label.

Focused is a state which exists since the early versions of tgui but which never evolved with it. It makes sense for basic widgets like button and edit box but widgets like slider don't support it at all. Pressing the tab key moved the focus from one widget to the next but once containers like panel and child window were added even this started giving issues. The point is that focusing support is somewhat broken and has to be rewritten from scratch to be really useful again.

Although there still is a function to set a focused texture (and Black.png even still contains the needed images), it is not even used by any of the themes that comes with tgui. When rewriting the widgets to support colors instead of textures, I didn't even take the effort to implement the focused state for colored widgets because it would have to be changed later anyway. That's why there is a function for a texture but not for a color.

I don't want to touch the focusing anywhere soon because even I don't know how edit box is currently functioning. Technically it is not allowed to be in focus state because it requires the focus image, but it can't receive text input if it is not focused. Most likely I solved this by somehow making EditBox and TextBox exceptions on the rule a long time ago.

I had to debug the issue to find out what was going wrong, but the mistake you made is that "Container" is a abstract class and it happens to be a valid widget type since it is used internally to load containers.

What you need is probably the Panel class.

The latest tgui version (which you can download from github) can now load layouts from a file but it can also save layouts based on strings to a file.

I improved the code some more so that you can also load something like this from a file:

Code (ini) Select Expand

Size: ("0.5 * parent.width", 50)

While adding the saving layouts to file I also found 2 bugs in tgui. One was just a minor thing but the second one was pretty serious. If you intent to call gui.remove or gui.removeAllWidgets in your code then I suggest you download the latest version because removing widgets could apparently result in hard to find crashes in certain situations.

Having a fixed tab width would indeed simplify the calculation a lot but I don't want it to be limited. But having a way to set a fixed width is not a bad idea. Right now you can only set a maximum tab width, I already wanted an option to set a minimum width so why not also add a function to set a fixed width.

Thinking about the fixed width actually made me come up with a good implementation for the setSize function. You just set a width (e.g. 400) and it will be divided by the amount of tabs you have. If you have only one tab it would be 400 width and once you add another one they both get a width of 200. I can't believe I never though of implementing it like that before. I would still leave an auto-size way like it currently is so that the size can depend on the text in the tabs and doesn't has to be a preset value.

But both additions are going to require me to rewrite most of the code in the tab widget since all calculations will have to change. Since I don't have time for such big changes right now I guess the setSize will just have to remain empty a bit longer. At least now I have an idea on what to write in it, which is more than I had before this topic started

The difference between windowed with such a high resolution and full screen probably is not big enough to show the stretching. Just try to make the width of the window 200 without changing the height while the program is running. If no setView function is called then it will stretch because the window is still using the 1280x800 resolution even though the window has a completely different ratio. If you don't see the text being squeezed by changing the width then you are not using the exact code than you send me.

I know my tab doesn't work decently without your code, but the problem is that I can't reproduce what you describe here. I would love to be able to make setSize work in the way that you describe with adapting setDistanceToSide but I just can't get it to work. The code you send still contains too many unrelated things (e.g. the 1000.0 contant) that make it harder to fully understand (plus running it as-is doesn't provide the effect that I hoped for either, otherwise I would get rid of the unrelated stuff myself).

I can't do much with the current code. I need to be able to clearly see the connection between the width of the window and the width of the tab, in the example I can't find a connection between the two. That's why I asked for an example where their widths are the same, then I can immediately see the connection.

I hope I'm not coming over as harsh, I really appreciate your help. I just can't turn what you showed so far in what I need to implement the setSize so that's why I ask to help me even more and reduce the code to the bare minimum so that there is a visible formula between the wanted size and the distance to side.

I still don't understand how this is all working.
Probably because it isn't working here

In your example code you are not changing the view of gui thus everything is just stretched instead of resized. Dropping the onResize line doesn't change anything. I hope this was just a mistake in the example?

I tried to change the view on resize but I'm not sure what the program is supposed to do. Changing the height of the window has no effect while changing the width doesn't give good results when I make the window smaller (and my screen isn't big enough to see if it gives good results if I make it much bigger ).

If you would be able to make an example where the width of the tab always equals the size of the window and the height of the tab is e.g. 1/20 of the window height then I will probably be able to convert the code into something that fits inside the setSize function.

After some changes (e.g. changing tabs to spaces) the final version looks like this:

Code (cpp) Select Expand

    tgui::Layout2d parseLayout(std::string str)
    {
        if (str.empty())
            throw tgui::Exception{"Failed to parse layout. String was empty."};

        // Check if the layout is an (x, y) vector or a quoted string
        if ((str.front() == '(') && (str.back() == ')'))
        {
            str = str.substr(1, str.length() - 2);

            auto commaPos = str.find(',');
            if (commaPos == std::string::npos)
                throw tgui::Exception{"Failed to parse layout '" + str + "'. Expected numbers separated with a comma."};

            if (str.find(',', commaPos + 1) != std::string::npos)
                throw tgui::Exception{"Failed to parse layout '" + str + "'. Expected only one comma."};

            return {tgui::stof(str.substr(0, commaPos)), tgui::stof(str.substr(commaPos + 1))};
        }
        else if ((str.front() == '"') && (str.back() == '"'))
        {
            str = str.substr(1, str.length() - 2);
            return {str};
        }
        else
            throw tgui::Exception{"Failed to parse layout '" + str + "'. Expected (x,y) or a quoted layout string."};
    }

Including Layout.hpp is actually not needed since it is such an important part of the gui that almost any header will (indirectly) include it.

I remember by now why I never implemented this before myself. I was going to implemented saving to file together with loading from file but when the layout is not a string there are situations in which it can't be saved correctly. But I don't see a problem with adding this loading now and adding saving to file later on.