Messages

Code (cpp) Select Expand

canvas->clear();

That code will clear the canvas with a black color.
Change it to

Code (cpp) Select Expand

canvas->clear(sf::Color::Transparent);

The Panel also has a background color. So you should add this line as well:

Code (cpp) Select Expand

panel->setBackgroundColor(sf::Color::Transparent);

Could you post some minimal code that does what you describe so that I can easily test it here?

What is the reason that you have the ratio identified as a string instead of passing 0.5 directly to insertSpace?
What function would you have to call to set the ratio of a widget?

and then maybe should I pull the TGUI github and make a pull request ?

That would probably be the easiest way for me, yes.
You just make a fork on github, make the changes in your forked repo and then send a pull request so that I can review the code before merging it.

Wow, this is really cool. I always wanted to add classes like that but I never found the time to do it.

If you're interested in theses classes, I can implement more features, like weight for each element, borders, fixed size widget and space elements.

I'm definitely interested in such classes.

Edit: I know that the copy constructor/assignement operator sounds bad, because widgets are copied, removed and copied again, but that's the only way I seen to don't have to write a addWidget method like you did with Grid.

I think it can be done easier if I make a small change in the Container class. The reason you have to write the copy constructor and assignement operator is because the ones in Container just copy their own variables. If instead I make it call the add function for all its widgets then your code should work without needing to implement these functions yourself.

Btw, perhaps it is just a typo and you already know this, but std::remove (which you use in BoxLayout::remove) doesn't remove anything.

For the Tab I might as well write a different widget for it. A lot of code in the tab widget is about the distance between the sides and the text and about auto scaling to fit the text. All of these things aren't necessary if every tab is an image. Trying to put both ways into the same widget will probably lead to even more redundant code. But it is definately a good idea to have a tab with images.
Edit: I was thinking about a Tab that didn't have any text on it like in the screenshot. To support both an image and text, it would have to be integrated in the same widget.

For Tooltip there are a few ways that it could get added. One way is to make it a panel, that would allow you to do anything on it, but it might become too complex. The other way is that the Label class evolves into a more complex class which allows rich text (possibly split in a e.g. a normal Label and a RichLabel class). Then tooltip would just inherit the rich text label. Or maybe something in between, something like you suggested, I'll think about this later.

So both ideas are added on my todo list, but only the first one is likely to be added in 0.7.

Customization is limited, but Tab and ChildWindow can use images.
ChildWindow uses a Button widget for the close button. Check the Black.conf file in the widgets folder for an example on how to customize it.
Tab can have a background image, but it has to be the same for every tab, so you can't give each tab a different look.
Tooltip doesn't just use a label, it is a label. So anything you can customize on a label can be done on a tooltip too.

But if you have more specific suggestions on what should be customizable and you can give some use case for it then I will add them on my todo list. They won't get added anywhere soon, but they will be looked at next time I'm making improvements to the widget.

A widget to create an interface like that has been requested several times. I still haven't figured out a decent way to implement it because there are so many variations in the requests (lines between the columns, name of the column on top, scrollbar, ability to highlight a line, images next to text, ...). So for now it isn't that easy to create something like that. But it definately is on the todo list for tgui 0.7, although it will be looked into after the release of 0.7.0.

The ability for Grid to automatically position its widgets when you call setSize was a feature that someone contributed to tgui. I never really took the time to fully understand that part of the code. Apparently I broke the feature when implementing the Layout system. I fixed it now, so it should work again if you download the latest version again.

It is very unintuitive, but due to the way Grid is currently written you have to call both the add and the addWidget functions.

Code (cpp) Select Expand

grid->add(label); // add the label to the grid like you add it to any other parent
grid->addWidget(label, i, j); // put the label in the correct cell in the grid

There shouldn't be any side effects of resetGLStates as long as you don't use opengl directly. But if you want to go this way then perhaps it would be better to put "window.pushGLStates()" and "window.popGLStates()" around the gui.draw call. That should also do the trick without messing with other code.

I understand how hard it is to find a bug like this, so I appreciate that you took the time to dig out where it went wrong exactly and report the bug.

I just copy-pasted parts of you example codes

Ah, I didn't knew it contained that code. I forgot to update it apparently after I allowed the bind function to take the Gui as parameter directly.

This one is really tricky and I have decided not to fix it (for the reason, see last paragraph of this post).

Just don't put the function calls on the Canvas between the clear and display of the window. Putting it right above it will work fine. If you do it this way then you can't create any problems.

The error only occurs when calling sf::RenderTexture::display right before calling gui.draw(). If any other draw call is between it then the code will work. The problem is that RenderTexture activates its own opengl context. All draw calls (also the one in tgui) will reset the context. But before tgui makes any draw calls it uses opengl for the clipping, and in this case it does that on the wrong context.

The solution on my side would be to simply call m_window->activate(true) inside the gui.draw call. Unfortunately this activate function is private. I know that I can easily call the function anyway, but I simply don't want to.

The reason I'm not going to fix it is because this code will be thrown away in the near future (hopefully). The only opengl code that I use is for clipping, and the only reason I implement clipping in my own code is because sfml does not provide clipping masks yet. So once sfml implements clipping masks I should be able to ditch all my opengl code and this problem will solve itself. The clipping masks in sfml are actually already kinda implemented, they just haven't been able to agree on a design yet. So I do expect it to be added to sfml before tgui 0.7.0 is released.

This is a really strange issue. It only occurs when the clear/draw/display of the canvas is done right before drawing the gui. Drawing the sprite to the canvas before the main loop makes the code work as expected. However a sf::RenderTexture does not seem to cause this behavior, while Canvas is just a simple wrapper around it. I'm still trying to figure out the difference between the two that breaks this code.

Calling "window.resetGLStates()" right before "gui.draw()" seems to solve it, so you can use that for now.

"tgui::bindWidth(gui.getContainer(), 0.5f)" can be written as "tgui::bindWidth(gui, 0.5f)" btw.

I can't reproduce it with the MinGW on my pc either. It really must be a combination of the libraries you have and the compiler.

Which compiler are you using exactly (you already said mingw 4.8, but there are 3 different mingw versions)? Could you send a link to the page where you downloaded it?

Also could you upload the TGUI and SFML libraries that you build somewhere?

Then I can test this problem under the exact same circumstances.

it asks for debug DLLs

Then just copy the dlls (which can be found in the lib folder inside the build folder that you created for cmake) next to the executable you are running (like you should have done for the release dlls already). You really need to run in debug mode to get most information.

I cannot get it again when I run my program with gdb, but when I run the program normally I get it.

Are you running it from the command prompt in both cases and in the same folder?

By the way, how can I help you to improve TGUI?

For short term stuff I created a page on Trello. You could have a look at the tasks in the "Minor changes" section.

Bad news, it even works in visual studio, which is usually more likely to give errors and crashes than mingw.

So you should double check that the TGUI and SFML libraries are compatible. Both should be linked in release or both in debug. Both should be static, or both should be dynamic. I assume you also compiled sfml yourself, so I guess there won't be a problem with one of the libraries being compiled for a different compiler.

I don't see how the layout system could be related to a crash about a texture, these parts of the code are completely separated. So it the problem really lies here then it is going to be hard to find. I also can't reproduce this on linux and my mingw compiler seems to be broken again.

First of all, you are not mixing debug/release or static/dynamic with each other, right? The sfml and tgui libraries have to be compiled with the same settings or very strange crashes can occur.

that's the only relevant information that the call stack gives

Call stacks on destructors indeed usually provide no relevant information, but if even one of these lines is about a tgui function then it might help. Are you linking in debug mode?

There is unfortunately not much that I can do to help right now. I'm going to try with visual studio now in the hope that it crashes there too. But if I can't find the problem in less than an hour you will have to wait until Thursday. Then I will also have the time to fix my mingw compiler.

The get function will look only at the direct children of the widget by default. Since the edit box is not a direct child of gui, it will not find it.

Every container widget actually has a get function, not just Gui, so you would have to do this:

Code (cpp) Select Expand

panel1->get("modelName");

I also added an option for get to search recursively some time ago, so this is also an option:

Code (cpp) Select Expand

gui.get("modelName", true);

This is just a bug in the old compiler, or something that wasn't implemented at that time.

If this is the only error then you can fix it by changing the line to

Code (cpp) Select Expand

GuiContainer::Ptr m_container = std::shared_ptr<GuiContainer>(new GuiContainer());

Although TGUI v0.7 supports the compiler from VS2013, I will not adapt my code to older compiler versions, I only guarantee support for up-to-date VS versions.

Are you perhaps specifying the middle part? If you specify the property ending with "_M" then tgui will also expect to find the "_L" and "_R" properties. But if you don't use any postfix then you should only have to pass a single image and it should not complain about missing left and right parts.

I understand what you mean now.
The buttons in the Black theme were indeed not meant to be square. They have a minimum width.
(in v0.7-dev I changed the behavior so that if you ask for 20x20 the image will display as 20x20. It will look really bad since the image is not made for it, but at least it does what you ask)

In order to make the button scalable, it is divided in a L (left), M (middle) and R (right) part. You can clearly see this in the Black.conf file. The left and right parts are squares here, and they will keep their ratio when scaled, only the middle part will stretch. So the button is always at least twice as width as it is high.

You could fix it in the Black theme by changing the lines in these forms:

Code Select Expand

NormalImage_L = "Black.png" ( 0, 25, 50, 50)
NormalImage_M = "Black.png" ( 50, 25, 100, 50)
NormalImage_R = "Black.png" (150, 25, 50, 50)

by this

Code Select Expand

NormalImage = "Black.png" ( 0, 200, 50, 50)
(the numbers between brackets is always left, top, width, height)

But it won't look good, so you best use your own images.

You should check out the v0.7-dev-gcc5 branch. I still have to do some tests to check if it still works on all other compilers, but it seems to work with gcc 5.

Fixed in the latest version of v0.7-dev branch.

it defaults to a rather large size

I'm not sure if you mean the button itself or the text on top of it.
You can change the button with the setSize function and the text size with the setTextSize function.

seems to be unavailable in .conf files altogether

The idea of config files is that they determine the theme, the way widgets look. So classes like AnimatedPicture do not load from it, since they have no "theme", it is just several frames op pictures. So you can only add those frames from code.

I tested it myself by now, even with c++14 it won't compile.

For now I have just disabled part of the callback system when the compiler version is 5. When you read the tutorials, just pretend you have a Visual Studio compiler, so when it says "gcc 4.8 or higher" then you can forget about using that part.

I will try to minimize the failing code when I have some more time and go ask the gcc developers if this is a mistake in their compiler or if I am just doing something illegal.

Edit: I figured out the mistake while minimizing the code. The problem is in my code, although I don't immediately see a way around it.

Shit, GCC 5 seems to have added static asserts to prevent wrong binding. The problem is that it is also asserting when it shouldn't. I'm relying on that code to detect what parameters the user passes. It worked fine in previous gcc and clang versions and it was even written in such a way that VS2013 can compile it although not supporting it (which is why this part of the code is very sensitive and can't easily be changed).

You could try compiling with -std=c++1y, since std::function is actually only unambiguous in c++14 standard but it worked fine in c++11 with gcc 4.8. If that doesn't work then I'm starting to fear that I will have to dump the most advanced part of my library.

But you won't have to go back to v0.6, I think I will be able to disable code in such a way that you get the same behavior as VS2013 currently has: only basic calls to the connect function (all internal calls are like that) and for getting actual callback you would have to use connectEx.