Messages

Sorry for double post.

There is no problem with double-posting. I actually prefer it over editing a post that you made hours earlier.

If you make a new post, I will get an email and read it. But I don't get a mail if you edit a post. If it's just a small edit or if the post was only a few minutes ago then editing is better, but if like in the other topic there is half a day between the post and the edit, then you should have made a new post instead.

I'm not strict with rules for editing or double posting, you should just do what you find best for that situation.

I've identified the problem why unique_ptr::~unique_ptr was not calling destructor, cuz they were not tagged as virtual

Damn virtual destructors in c++
I can think of reasons why they don't do it, but it would be so much easier if they were virtual automatically once you inherit from the class

Could you provide a minimal and complete code that does not work for you?
The callback seems to work fine here.

I of course don't know how skilled you are (its hard to say based on a few post), but unless you know what you are doing: don't use multi-threading. Its very attractive because beginners think it will make their code run faster, but in reality you probably don't need this small improvement and it will only give you headaches. Once you start using mutexes everywhere, you basically fall back to the same speed as a single threaded program. So a multi-threaded program has to be very carefully designed.
My advice: think carefully about whether you really need a separate thread for rendering.

BTW: Render is in another thread.

That complicates things a lot of course.

Neither sfml or tgui is thread safe, so you are responsible on making sure that you aren't changing anything while rendering it.

Calling removeAllWidgets without a mutex could indeed make your screen blink, but calling any other function on a widget could also give a strange artifact on that widget in that frame.

i don't use 0.7 because every single resource has to be loaded directly from disk instead of giving reference as in 0.6.6

Its perfectly ok to still use v0.6, the new version still has its limitations. But I didn't understand that line, 0.7 should be better in any way regarding loading widgets (it just doesn't support loading widgets from a text file yet like 0.6 does).

This is a limitation in the way v0.6 works.

You aren't supposed to be using the gui.add function directly.
A better method would be to write:

Code (cpp) Select Expand

m_button = tgui::Button::Ptr(*fw::g_gui);
m_button->load(THEME_CONFIG_FILE);
m_button->...By doing so, the widget is fully initialized before you call any functions on it.

If all widgets need the same font, then instead of calling setTextFont on every widget you could also write the following on top of the construct method:

Code (cpp) Select Expand

fw::g_gui->setGlobalFont(Assets::Data::getFont("font"));That would also have solved this problem.

I may have an idea about what the bug could be.
Could you try calling "widget->setTextFont(...)" after you call "fw::g_gui->add(widget)"?

But if that doesn't solve the problem then I'm going to need a minimal code that I can test myself.

i cant use function tgui::Gui::removeAllWidgets() because certain things must be still visible (it sucks when your game screen blinks)

Your screen is only updated when drawing. If you call removeAllWidgets and then add the needed widgets before you update your screen then nothing will blink. Of course recreating widgets takes time and it is slightly more efficient to keep the ones that you need, but I just though I should mention it.

Since you are not using the constructor of the button to initialize it like in the example codes (which I admit is sometimes practically impossible in v0.6 when having the widget in a class), could you show me the code where you actually create the widget?

If no text shows up it means that there is no font. The font is normally set with gui.setGlobalFont and then passed to the widget when connecting it to the gui.

It is really hard to say what is going wrong without seeing the contents of the construct method.

PS: Is there any reason why u don't use normal constructors and destructors?

I found the problem.

When you add the menu to the gui, it is given the width of the gui. This was done so that you didn't have to specify a width for the menu bar as it would just fill the whole width.

I'll fix it so that it will only give the menu bar a width when the width has not yet manually been set (ie different from 0).

But in the meantime just call the setSize function after the mGui.add(menu) line, that will make the code work.

This seems to be a bug.
I'll see if I can find what is causing this exactly.

Btw, tgui::bindWidth(mGui.getContainer()) can also be written as tgui::bindWidth(mGui).

only third solution work for me ( gcc 4.7.2 with mingw on win7 )

Interesting. I though gcc 4.7 was the minimum compiler that my code supported. So either the MinGW port just isn't as good as it should be, or the minimum support is gcc 4.8. I guess I will have to look into that.

The only limitation of the third method is that you cannot have multiple menu items with the same name in different menus. But usually that isn't a problem.

The examples are poor for the potential of this lib.

Feel free to write your own examples and send them to me

There are two ways to do it, depending on which compilers you want to support.

The first way will only work on the latest compilers (not with VS), but it the nicest one to use.

Code Select Expand


void my_func(sf::String param); // param == "Quitter", param could also be an std::string if wanted
menu->connect("MenuItemClicked", my_func);

void my_func2(std::vector<sf::String> param); // param[0] = "Fichier", param[1] = "Quitter"
menu->connect("MenuItemClicked", my_func2);


The second method is the legacy method which uses the Callback class from v0.6.

Code Select Expand


void my_func(const tgui::Callback& c); // c.text == "Quitter"
menu->connectEx("MenuItemClicked", my_func2);


The information for which parameters can be used for which widget can always be found in the Documentation.

All crashes that I have seen so far on windows were related to incompatible settings in tgui and sfml.
So you should double check everything mentioned here and answer the questions at the end if you are sure that everything is setup correctly. https://forum.tgui.eu/index.php?topic=216.msg1092#msg1092

the question is if you would write them manually in the first place

That is indeed an interesting question which I haven't thought about much. They will most likely have to be edited manually, but that only requires some small changes and most of the files could indeed be generated.

However, the form builder is unable to create more complex scenes. I'm not even sure if I will add it again in v0.7. It would be a great addition to have, but it takes way too much time to write and maintain and it is extremely hard to support complex things like widgets inside panels or relative positioning. And the way themes are going to work in v0.7 probably don't make it any easier.

The reason why one might write it in a text file instead of directly in the code is to avoid recompilation when e.g. only slightly changing the widget positions. So there is still some use case for writing these files by hand without putting them in the cpp file. Which is why I like it to be as readable as possible.

And file size shouldn't be a concern.

Neither file size or speed is a concern for me. It is just the readability that bothers me with xml.
But the original idea was to use xml, so maybe I should reconsider it. More people will know how to write xml than json files anyway. But we will see, I still tend to like json better.

simply because libconfig uses ascii for strings which is undesirable if you do ButtonText = "MinButtøn".

This is a valid concern, but also one that should be made for json. The jsoncons library that I was looking at also works with stings by default. I would have to read the file myself and pass the stream to jsoncons, but I even wonder if std::ifstream supports unicode.

I have though about XML, but I kindof see JSON as its successor.
XML requires you to open and close tags which means you have to write things twice.

I would choose the second or third opposed to the first one. The third one looks best here, but these key-value pairs like now are too limited.

Code Select Expand

<TextSize>5</TextSize>
"TextSize" : 5
TextSize = 5

These folders are not there in the official release, but I just checked and there isn't even an official release for VS2013. So I'm not sure where you got these libraries from, but the folder structure was not the same as the ones from the sfml website.

But it was the same problem as when you would compile sfml yourself. Visual Studio always creates these damn debug and release folders instead of just putting the libraries where you ask them to go.

The lib folder actually contains two sub-directories "Debug" and "Release".

That's wrong. Copy the contents of these folders directly into the lib folder. That will solve the problem.

I'm not sure how the external libraries popped up on CMake the first time

My cmake script detects them automatically if all goes right. But usually if it finds the external libs it also finds the sfml libs, that's why I was asking about it.

That's weird.

SFML-2.1 contains the files downloaded from the sfml website (i.e. you didn't compile them yourself)?
So the lib folder contains no subfolders and has the dynamic release libraries in it directly?

Did you fill in anything manually in cmake except for SFML_ROOT? Like the include folder or the extlibs?

You might also want to check the "Advanced" checkbox and see if it finds some sfml libraries or simple none at all.

In v0.6, you have to pass the child window to the constructor of the widget. But you have to remember to dereference the pointer, otherwise you will get some very strange errors.

Code Select Expand

tgui::ChildWindow::Ptr child(gui);
child->load("Black.conf");

tgui::ChatBox::Ptr chatBox(*child);
chatBox->load("Black.conf");

In v0.7-dev you would just use the add function.

Code Select Expand

auto child = tgui::ChildWindow::create("Black.conf");
gui.add(child);

auto chatBox = tgui::ChatBox::create("Black.conf");
child->add(chatBox);

I always used the MinGW compiler that is shipped with CodeBlocks and I never installed a different one. So I can't give you much advise.

If you are sure that your PATH variable does not contain another mingw directory, then you should try clearing the cmake cache and rebuild again. Maybe it cached some old directory.

You are using separate build folders for the debug and release mode, right? There used to be a caching problem when switching from debug to release without deleting the cache. It is fixed in sfml by now but I never tested whether it really is fixed with my unchanged tgui cmake script. But if you use separate directories, like you should, then this can't be a problem.

Do the files still have a different size? If they have then you shouldn't be looking at the codeblocks settings.
If they are the same size then you could try replacing his dll files by yours. If that work then it means he has been using dll files from a wrong folder.

The smallest mistake can have disastrous consequences. But there has to be some mistake, the fact that it runs on your pc proves this.

Everything relevant has already been mentioned by eXpl0it3r.

There must still be a configuration mistake on his pc then.
Since debug works and release does not, you should make sure that the release settings don't still use a library that was build with another compiler. Also check that you use the right dll files in release.

If you have multiple sfml and tgui folders you should remove them to make sure that you can't be using the wrong one accidentally. And make sure that all dll files are coming from these folders.

Somewhere, something is still misconfigured. You just have to find out where .

And indeed, you could just give your libraries to your friend to make it work. But I agree with eXpl0it3r that it might be better if he can build his own libs. But it is an option if you really can't figure it out.

Looks like a serious project. It's good to see how some people use tgui, that way I can try to keep everything compatible or even make things easier when I rewrite a big part of my gui.

Then on some elements, I change properties via getRenderer() because I didn't want an extra theme.conf for a single Button

The Theme class would simply contain the same contents as the .conf files. So you would just have to make a changeProperty call on the theme before you pass it to the widget instead of needing an entirely different file where only one line has changed. The renderer could perhaps be kept internally and no longer needed directly. But it's too early to think about that.

Just in case you didn't know this yet: in v0.7 you don't need a separate file for every button. You can have multiple sections for buttons (or other widgets), just give them a name other than the default "Button" and pass the name as second parameter of the Button::create function.

What would happen if I create an element with a theme object and later I want to change a property on this element only?

If you change the theme then it changes on all widgets. But currently the plan is to duplicate the theme on a getRenderer call. So when you do "button->getRenderer()->setXyz(xyz);" then the theme is cloned and the change is made in the theme of that one button. Any changes to the original theme will no longer affect the button.

But this is not something you should worry about. I actually don't have the time to add features, especially as big as the theme rewrite. The exact way of how the themes and renderer classes work together hasn't been decided and I'm still far away from actually implementing this Theme class.

The bug is really minor

Nevertheless, it has to be fixed.

Linux is maybe a little bit too forgiving for bugs. It segfaulted in release mode, but then I didn't have a call stack. But in debug mode it just worked, even though I found out that I was accessing an element with index -1 in a list.

Anyway, it should be fixed now .

you should maybe compile a list for new users

Its all in the documentation, just split over multiple pages.
I understand that it would be a lot better to have a full list somewhere, but it would take a lot of work to do it for all widgets and I have so many other things to do already.

Although having tutorials is something needed for the project, in my position it is seen a bit as a waste of time. It costs me a lot of time, while I make no progress with the project. Yet it is a must because otherwise people can't use the project. It would be great if there were tutorials written by the tgui users .

I found a little bug

I'll look into it.

There is no single list containing all signals.
But the documentation contains such a list in the "detailed description": https://tgui.eu/documentation/v0.7/classtgui_1_1ListBox.html#details

At the bottom of that list you find "Inherited signals from ..." and when you click on that class name you can again find a list for all widgets that inherit from that class.