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

[texus]

TGUI v0.4 is now officially released.

To celebrate this, I have created a new style, called "BabyBlue" (actually I copied most of it from Michael Donovan's Baby Blue UI Kit).
It can be used as an alternative to the default Black style.

Here is a screenshot of the new style:



The goals for TGUI v0.5 are not yet set, but I was thinking about adding child windows.
For the rest it will be mostly improvements to what I have already instead of adding new things.

[pighead10]

I've found a fairly severe bug with tgui (unless I'm doing something wrong). I created a window which is 800x600, and a button which is 600x600, but I have also used a sf::View. The view is created in a larger rectangle so that anything originally 200x200 looks 25x25. This works correctly with the button - the 600x600 button does not take up much of the screen - but the area in which I can click it does not adjust. If I click on the button, it doesn't work, but if I click anywhere where a 600x600 button would be without a sf::View, the button clicks.

[texus]

This is indeed a serious bug.
Edit: It is fixed now.

[pighead10]

Is the fixed version available for download?

[texus]

Yes, any download you find should contain the fix.

[pighead10]

Also, the form builder crashes whenever I try and load.
EDIT: On the newest version it doesn't.

[texus]

I am going to need a little bit more information about that.
I tested the form builder yesterday on my windows 7.

What do you mean by 'crashes'? Does it give an error?
If it just immediately closes without giving an error then it is because it can't find the images folder or the 'FormObjectWindow.txt' file. They should be in the same folder as the executable. In the future I will make it output an error for this, but currently the program just closes.

If it does crash with an error then you should give me the error and the way you have build tgui (OS, compiler, static/dynamic linking).

EDIT: Yes there was indeed a small problem with it in the original release, but I've made the fix together with the view problem. I though you were saying that there was a problem with the latest version.

[pighead10]

Yes, on the version I was using (the one with the View crashes) whenever I pressed 'load' it would just stop responding and windows would close it. It's fixed in the latest version, so now I finally have a working GUI for my game!

I've found what I think is an issue with hide(), though. I am running this code:

void TguiWidget::hide(){
        for(std::map<std::string,std::shared_ptr<tgui::OBJECT>>::iterator it = objects.begin();it!=objects.end();it++){
                it->second->hide();
        }
        displayed = false;
}

`objects` contains a Button, Label and Button, 'wood_icon', 'money_icon', and 'shop_exit' respectively. 'money_icon' and 'shop_exit' are hidden fine, but 'wood_icon' stays on the screen. Its events get disabled - hovering over it doesn't change anything and it doesn't register any clicks even though the callbackID is not 0 - but you can still see it.

I used the form builder for this. I've attached the form.txt.


[attachment deleted by admin]

[texus]

Ok, it is indeed a bug. Thanks for finding it.
There was something wrong with my drawing code: when ALL objects are invisible then the first object was still drawn.

I've called the fixed version v0.4.1.

[StevenC]

Hello Texus,

Great work on TGUI. I found it very useful for my JSGameClient project.

I made one significant change for my own use which I thought I would report back on:

I didn't like that the developer has to use a descendant of the RenderWindow class in order to use TGUI so I created a Form class (a modified Window) that removes the subclass and instead requires a sf::RenderWindow * in the constructor. I thought I would recommend this change be included in the main TGUI as an alternative to using the Window class for those like me who think subclassing an SFML Window is unnecessarily restrictive.

One "issue" I encountered was the Panel class hides some public members mouseOnObject, addCallback, and another one. Easy for me to change so no big deal.

A recommendation I have aside from the two things mentioned above would be to remove the loading from a file function in Window and make the loader a separate method or even better break it up and make it a class.

Anyway, I found TGUI very easy to hack on and I really appreciate how you structured the project. I made a V8 JavaScript binding for the modified version so that the TGUI can be accessed from JavaScript.

Thank you,
-Steven

[texus]

I am glad you found the project useful.

Deriving the window from RenderWindow is done to make it easier to use and I don't see any reason why you would want to split them. What restriction is there? In the changelog on GitHub you said that it would make it possible to have multiple forms, but as I already commented there this can be easily done with panels. If you of course see another reason then feel free to share it, but for the moment I don't see any advantages of such a change.

Is there any reason why you want to access these funtions from Panel? I don't see why you would need them.
I would make the mouseOnObject function public, just because it is public in all other objects, but I have no motivation for making the addCallback function public. If you want to fake a callback, then add it directly to the queue in window instead of making my panel send it to the window.

The loading from file function should be rewritten in the future anyway, so I am open for such suggestions.
But I am not sure how I could take it out of the window. The function has to add the objects to a parent in order to load them.
It is worth thinking of, but it won't be for soon.

[StevenC]

Hello Texus,

As I stated above:

I didn't like that the developer has to use a descendant of the RenderWindow class in order to use TGUI

No point trying to understand it. It is like trying to say why one person considers Picaso a great artist and another person looks at it and says "meh."

The suggestion is just an idea, offered for my own benefit. A recommendation to implement these changes would save me time if you would accept them and I could spend less time keeping the custom TGUI in sync, so it falls under the category of there being "no charge for asking you." But I did so with the an expectation of rejection.. Most programmers I know don't like being asked to change their stuff and I myself am no exception.. 

-Steven

[texus]

I see no disadvantages, it would make you happy and it only takes a few minutes, so why wouldn't I change it?
The Form class can be usefull in the future too if I ever decide to port my project to sdl.

I'll make the following changes in v0.5 within the next few days.
- There will be a Form class (it will still have the loadObjectsFromFile function).
- mouseOnObject and objectFocused will become public in Panel (addCallback will stay private, you will never need it)

[StevenC]

Thanks Texus, that is really nice of you. The Group class defines addCallback as public which is why it was giving me issues. There was a couple ways I could work around it, but the easiest seemed to be making it public in the descendant as well. I assumed it was simply an oversight and you intended it to be public.

-Steven

[Khaos]

http://i.imgur.com/RUUsy.png

I am a novice when it comes to cmake. At first I had an issue with finding the CMAKE directory so I changed it to the mingw located in Code::Blocks

Now I can't get past this. I have just recently dove into stuff like this and am not quite sure what it's looking to fix.

Thanks for any help.