TGUI: a c++ GUI for SFML (with Form Builder)

[netrick]

Is there an automatic way to remove all objects of one type or I have to manually loop over all my objects?

[texus]

You have to do it manually.
There will not be a way to do this because then the window would have to distinct between the different objects.

An alternative to looping over all objects would be to store the pointers to the objects yourself and then just call window.remove(...) with those pointers as parameter to that remove function.
But even this would mean looping over several objects.

[texus]

Form has now been merged into Window.

If you were using tgui:Window then nothing should have changed.

If you were using tgui::Form and you decide to update to the newer version then you'll have to change 2 things:
- "tgui::Form gui(sfmlWindow);" changes into "tgui::Window gui(sfmlWindow);"
- The draw function is now called drawGUI

[netrick]

That window change makes it somewhere easier. If you look for example at Irrlicht, they also have gui merged with render.

I think there is some incosistency. Currently it is:

obj->setCallbackId();
callback.callbackID;
 

First, there is 'd' and 'D' difference. Second, double callback is kinda unnecesarry. It should be:

obj->setCallbackId(); //so it stays as it is
tgui::Callback callback;
callback.Id; //the same case as in set function and it makes much more sense
 

You dont use vector2u.vector2uX, do you?

[texus]

I had already spotted the D in callbackID, thus it has already been changed in the latest version.

callbackId could indeed become id, but without the capital letter. Functions and variables are in camelCase notation, so if I would make it start with a capital letter I would really have inconsistency.

And I don't use Vector2 because it isn't possible in a union. Although I am already considering to just drop the union as it isn't really needed.

[netrick]

Yea callback.id seems fine to me. And as for the vector2 example, I didn't mean it. I just wanted to show that object.objectId is unnecessary.

Btw, objects in panel use relative positions to the panel yes? Because I think I have something messed up in my code.

[texus]

Btw, objects in panel use relative positions to the panel yes?

Yes

[netrick]

Newest github version doesnt compile because of form builder using old callbackId. I need to compile new version as for some reason when I updated recently tgui callbacks stopped to work (or maybe poll callback function) so I want to update to see if it helps.

[texus]

I sometimes forget to test the form builder after making changes.
It has been fixed now.

[netrick]

Thanks.

Also, I report a bug.
If I'm correct, tgui::Window no longer derives from sfml::RenderWindow. This is a big problem, because now I can't treat tgui window the same as sfml window and it causes unnecesary problems. Now this code doesn't work:

tgui::Window window(...);
sf::Mouse::getPosition(window); //it used to work because tgui::Window derived from sf::RenderWindow
 

I doubt that it's my fault that my code no longer compiles as I didn't touch that part of my code for some time.

EDIT:
I know what you wanted to achieve with one object which can be either window or just form, however this broke some things up. tgui::Window must derive from sf::RenderWindow as there are functions which take RenderWindow argument.

Please, revert it. It completely broke my engine and there are good reasons to make tgui::Window the same as sf::RenderWindow as it used to be.

[texus]

I didn't saw that one coming when removing the inheritance.

I'm not going to revert the change, so you'll have to split tgui::Window and sf::RenderWindow. Check the tutorial in the "Alternative usage" section.

You can either split them completely or just keep doing everything with the tgui window, but in the sf::Mouse::getPosition you will have to use the sfml window.

[netrick]

That's a sad news you don't want to revert it. Few days ago when you said that you rather want to get rid of tgui::Form I rewrited many parts of my engine (and like 300 calls in my app) to use single tgui::Window for everything.
Well, seems like I need to rewrite it yet again to separate tgui and sfml.

Don't you think that tgui::Window is now somewhat broken as it can't behave like sf::RenderWindow?
One is forced to use separate sf::RenderWindow unless doing some very basic tasks with sfml. I think mouse input is quite important and widely used.

There should be both form and window, it was much much easier and better designed as we see in the long run. I didn't thought that removing tgui::Form wil remove inheritance.

[texus]

Would it help if I would just add a getMousePosition function to tgui::Window or are there more problems than that function?

Actually the functions in tgui::Window are only provided for simple usage, because in the future you might even be forced to split the windows (although I'll try not to do that as long as possible). A while ago I was told that I shouldn't inherit from sf::RenderWindow and I dissagreed but I added tgui::Form for those people. However now I know that keeping the inheritance will give me some limitations that I rather don't have. That is why I decided that tgui::Window should be more like tgui::Form was.

[netrick]

Besides our discussion, do callbacks by id (ie 0.5 way) work for you on the newest snapshot? Because with the newest snapshot they stopped working for me and I doubt I changed something in code... I could accidentaly change something but I'm not sure. I just set callback.id for radiobutton and it never gets called.

EDIT:
Nevermind, I forgot that for id based callbacks I also need to use bind function in 0.6. It's working.

[china92]

@texus
First of all - many thanks for this library, this is the best-looking GUI for the sfml I have found. I'm currently making some tower defence game and it really helped me.

Ok, but that's not why I'm writing this post. I found some issues, and I decided to write them down inhere.

So, your library has problems with the inherited functions, for example in Label, when you use setOrigin method, it does not set the origin, but instead of that it moves the text in label so that the origin you have set is in the top-left corner (I'm assuming it happens in every other GUI element, but I haven't checked that). Maybe a picture will show it in the better way:


Also, in the loading bar, when you use setText method it works well, but when you move loading bar (setPostition method), it does not move the text, but only the loading bar, and the text is not show when it's out of bounds.

I have one question too: when you will release the next version? I'm asking because on your site you have written:

WARNING: I am depreciating the above code because it will no longer work in the future. Read the alternative usage to find out how you should use tgui::Window. If you use the method below then you will only need minor changes when I effectively make the planned design change.

But it doesn't work right now.

Regards

PS
Sorry for my English, I hope you understand all.