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

[texus]

I never had overlapping text. Could you show me how you initialize the checkbox?
I can only fix it when I can reproduce the problem, so if I have the code against tomorrow then I will see what I can do.

Did you by any chance change the text size? I know that this was never fully tested.
But if you did change it, what happens when you don't change it?

[CombatWombat]

Loading font...

sf::Font defaultFont;
defaultFont.loadFromFile("Fonts/DejaVuSans.ttf");
...
tgui::Window window(mode, "Terran Command 0.0001 Alpha");
window.globalFont = defaultFont;
 

Code for panel checkbox is inside:

    tgui::Panel* menuPanel = window.add<tgui::Panel>("menuPanel");
    menuPanel->load(500,300, sf::Color(50,50,50,175));
    menuPanel->setPosition(0,35);

Code for checkbox...

    tgui::Checkbox* checkbox = menuPanel->add<tgui::Checkbox>("Fullscreen");
    checkbox->load("Gui/Checkbox/Black");
    checkbox->setText("Fullscreen");
    checkbox->setSize(25,25);
    checkbox->setPosition(15, 15);
    checkbox->callbackID = 2;

Drawing code:

        window.clear();
        window.setView( window.getDefaultView() );
        window.draw(bg0);

        window.setView(mainView);  // Set view for drawing game objects

        vertexArray.s = texPage.GetTexPage();       // Select texturePage for vertexArray
        window.draw(vertexArray, vertexArray.s);    // Draw vertexArray

        window.setView( window.getDefaultView() );
        window.drawGUI();

        window.display();

I don't rescale the text anywhere and am using the default "Black" theme.

[texus]

It is fixed now.

[texus]

The Grid and Tab objects are now finished.
Grid is the first object that allows you to position objects relatively to each other, so you won't have to use exact positions for every object.

As with all objects you can find tutorials for the basics and you can take a look at the documentation to find the more advanced functions.

[CombatWombat]

So,

Any specific strategies for using this on a "larger" scale.  I only have a few buttons, and already I can see that hard coding each panel and having a giant "switch" block in the callback loop is pretty much unwieldy and error prone. 

Should I wrap panel in my own class and load things like position, size, text, etc from XML or similar files?
Do you just make one generic "OK/Cancel" confirmation dialogue box and show() it when needed.  If so, how to hook his outputs to different targets?

[texus]

Any specific strategies for using this on a "larger" scale. I only have a few buttons, and already I can see that hard coding each panel and having a giant "switch" block in the callback loop is pretty much unwieldy and error prone.

If you have any suggestions on how to make my gui easier for bigger projects, there always welcome.

If you have a lot of objects then you could reduce the loading to a single line by loading them from my object files which can be generated by the form builder. You will have to add Panels manually as the form builder doesn't support them yet, or you could output a file with the form builder and load its objects into the panel. The object files are loaded like 'window.loadObjectsFromFile("form.txt")' which is a lot shorter than loading every object one by one, but loading will of course be slower.

For the callbacks you will have to put a little bit more structure in your code. In bigger projects you will probably have different game phases of which each handles their own callbacks. So you will get a few callbacks loops of which each checks a few ids instead of having one giant loop that checks for all ids during all phases of the game.

Do you just make one generic "OK/Cancel" confirmation dialogue box and show() it when needed.  If so, how to hook his outputs to different targets?

I provide the means to create such a dialog box, but how you do it and what you are going to do with it is completely up to you.
I don't think I can help with how to hook its output.

[model76]

Should I wrap panel in my own class and load things like position, size, text, etc from XML or similar files?

In my project, I have a GUI class that handles anything to do with widgets. The styles are simply hard-coded in the constructor, and positioning is done in another method so I can easily handle window resizing.
That also makes it relatively easy to switch to a different GUI system, if I so desire, because all calls to TGUI are encasulated in that class.

If you have any suggestions on how to make my gui easier for bigger projects, there always welcome.

I still think using function callbacks would be the best solution for widget events. Getters for states like isFocussed is fine.
If I was to revive my own GUI project today, that is what I would aim for.

[texus]

I still think using function callbacks would be the best solution for widget events.

Would it be enough if I would provide a class with a virtual handleEvent function? You would just have to derive your class from it and then the function would be called instantly when a callback occurs. If you do not derive from the class then the callbacks would still be handled like now. At least this is what I had in mind for v0.6.

I am also willing to give every object a seperate callback function, but all callbacks from the objects will still be send to it. I won't allow different callback functions for mouse hover, mouse click, key press, ...
Especially not now I am making plans to add callbacks like mouseEnter, mouseLeave, focused, unfocused, ...

[model76]

Would it be enough if I would provide a class with a virtual handleEvent function? You would just have to derive your class from it and then the function would be called instantly when a callback occurs. If you do not derive from the class then the callbacks would still be handled like now. At least this is what I had in mind for v0.6.

That might be useful, although it wouldn't be a callback. What is enough is entirely up to you - it is your library after all.

I am also willing to give every object a seperate callback function, but all callbacks from the objects will still be send to it. I won't allow different callback functions for mouse hover, mouse click, key press, ...
Especially not now I am making plans to add callbacks like mouseEnter, mouseLeave, focused, unfocused, ...

The down-side to not implementing the filtering on your side will of course be that the user will have to do it on their side.
If you go this route, whatever you do, at least make sure you can register both free functions and members.

Also, I can certainly understand why you won't allow callbacks for mouse hover, since that is more of a persistent state than an event. 

[texus]

I have just made a lot of internal fixes, mainly problems with scaling objects.

The difference between setSize and setScale should now be very clear in (almost) all objects.
When using setSize, the object will resize itself, whereas setScale will simply stretch the object.
So in e.g. a ListBox, setScale will scale the text and borders while setSize will simply provide more space for the text.
So you should still be using setSize in almost all situations.

I have also made a few fixes of objects with blurry text. If you still find a situation in which an object has blurry text, then just let me know and provide a bit of code to reproduce it.

When updating to this version, you might notice that Slider::verticalScroll is no longer public and can no longer be changed directly. You must now use the setVerticalScroll function. This was done to fix a small bug in the slider.
I made a few bug fixes in Scrollbar as well, but you shouldn't notice them.

The down-side to not implementing the filtering on your side will of course be that the user will have to do it on their side.

I was thinking in letting you choose which callback you receive. All callbacks will still be send to one function, but at least you will only get the relevant callbacks. Like this, you won't have to filter them when you only need a single callback for the object.
It should become something like this:

button->callbacks = tgui::Button::MouseEnter | tgui::Button::MouseLeave | tgui::Button::MouseClick;

So you will be able to simply pick the callbacks you want for all objects.
But of course these are just plans for a future version and a lot can be changed before I even start writing it.

What is enough is entirely up to you - it is your library after all.

Yes, but I am not the person who uses it, at least not right now. So I try to base my decisions mostly on other opinions (and on the few things that I will need in the future myself).

[Cpl.Bator]

hi, congratulation for your work.

How can i set the size for tgui::Slider ?
if i use setSize() method , i have got display bug.  i think the bug is at line 871 of slider.cpp.

[texus]

It took my a moment to find the right line because your tgui version seems to be more than two weeks old.

I think that you are changing verticalScroll after you have called setSize.
The bug should have been fixed by now. In the latest version you can no longer access verticalScroll directly and you must call setVerticalScroll.

[Cpl.Bator]

I think that you are changing verticalScroll after you have called setSize.

Yes, work fine now. thanks.

[Haikarainen]

I'm having trouble compiling tgui (Git-version) using GCC in Linux with the latest SFML git.

-- The C compiler identification is GNU 4.7.1
-- The CXX compiler identification is GNU 4.7.1
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Found SFML: /usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: /var/aur/sfml-tgui-git/src/TGUI-build
Scanning dependencies of target tgui
[  4%] Building CXX object src/TGUI/CMakeFiles/tgui.dir/TGUI.cpp.o
[  8%] Building CXX object src/TGUI/CMakeFiles/tgui.dir/Objects.cpp.o
[ 12%] Building CXX object src/TGUI/CMakeFiles/tgui.dir/Label.cpp.o
/var/aur/sfml-tgui-git/src/TGUI/src/TGUI/Label.cpp: In member function ‘const sf::Font& tgui::Label::getTextFont()’:
/var/aur/sfml-tgui-git/src/TGUI/src/TGUI/Label.cpp:106:29: error: invalid initialization of reference of type ‘const sf::Font&’ from expression of type ‘const sf::Font*’
make[2]: *** [src/TGUI/CMakeFiles/tgui.dir/Label.cpp.o] Error 1
make[1]: *** [src/TGUI/CMakeFiles/tgui.dir/all] Error 2
make: *** [all] Error 2

[texus]

The master branch is still v0.4 which only works with the RC version of sfml.
You must download the v0.5-dev branch.