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

[texus]

I wouldn't know why the moveToBack works in only one of the two cases, but from what I saw when I was debugging this morning, I am even suprised that it works in one case. In my tests, the pointer was deleted at the end of the for loop and the program would just crash at the next draw call.

I don't know if you already tested with the version that I uploaded this morning, but for the rest there is nothing I can do. When I started with this gui I made the choice to store all objects inside the window and returning pointers to those objects so that you can change them. I did this because you wouldn't have to store the objects yourself, nor would you have to take care of cleaning them up. But the smart pointer just seems to take too much ownership and destroys the object when the pointer goes out of scope.

If you want to keep using my gui then there will be no other way then to change your design, as I can't change mine anymore. I don't like to say this, but the only solution I see is either to not store the objects, using the get function to retreive them and use normal pointers, or find another gui. In both cases you will have to redesign your framework.

Don't understand me wrong, I am still open for suggestions on how to improve my gui, but I just don't see a way how I can fix this problem on my side.

[pighead10]

I'm not using the latest version right now, so I'll post what happens when I am. I'll find a way around it.

[maxi1976]

There seems to be a nasty crash in the 0.5 version of TGUI with editboxes. I use SFML 2.0 RC.
It happens when you write something in an editbox and then highlight the first character in it, the same happens when you do a double left click in the editbox becouse that too would hightlight the first character.  The same functions work on textboxes perfectly without crashes.

The crash happens at the drawGUI() function
Microsoft Visual Studio C Runtime Library has detected a fatal error in insertnamehere.exe.

The culprit maybe the variable called m_SelChars. By editing the source code in EditBox.cpp
void EditBox::leftMousePressed(float x, float y) by setting m_SelChars to 0 instead of m_Text.getSize()
the crash seems to be gone, but it  ruins the highlighting.

[texus]

It is fixed now.
Thanks.

[model76]

Hi texus,

I have been thinking about trying tgui for a while now, but a single design decision has kept me from doing so:
The replacement of sf::RenderWindow with tgui::Window.

What is the rationale behind this? It seems rather intrusive to me. I would much rather see this than what you have now:

#include <SFML/Graphics.hpp>
#include <TGUI/TGUI.hpp>

int main()
{
   sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI window");
   tgui::GUI gui(window);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();

            gui.handleEvent(event);
        }

        window.clear();
        gui.draw();
        window.display();
    }

    return EXIT_SUCCESS;
}

It is literally 2 extra lines than the current solution, providing clear separation between TGUI and SFML, and extra documentation.

Besides, what if someone was to make, say, a particle engine that also replaced sf::RenderWindow? Then we wouldn't be able to use it together with TGUI. It is just bad practice in my (not so) humble opinion.

[texus]

Someone else has already said this before and I have already implemented it.
If you are using v0.5 then you can just change GUI with Form and your code should work.

It looked easier to my to do everything with the same window that is why the Form wasn't in the tutorials.

[model76]

Yeah, I thought someone else might have had the same opinion, and I admit I didn't bother to read through all 9 pages in this thread.

Anyway, it's a good thing you at least gave the option to not use the tgui::Window class, and I guess I will download TGUI and give it a whirl, then.

I have also bee trying out SFGUI after dropping my own GUI project, and I am glad that there now are several options for GUI systems. Keep it up, texus!

[model76]

I've started playing around with TGUI, and have a suggestion:
Why don't you change the private widget members and methods to protected? That way people could expand and modify existing widgets instead of always having to write new ones from scratch.

Example:
I need a history window to display and interact with undo actions, and the Listbox is almost perfect for that. All I need to do is remove the ability to deselect an entry, so one will always be selected, and change the text color of the entries below the selected entry. If the private members were protected, I could simply inherit the Listbox, add the members I needed, and overwrite the appropriate methods.

[texus]

As this isn't really a high priority, it will have to wait until I have my Grid and Tab objects finished.
For now you can just copy the whole listbox to an new file and edit it. So you don't really have to start writing it from scratch.

[model76]

For now you can just copy the whole listbox to an new file and edit it. So you don't really have to start writing it from scratch.

That is exactly what I am trying to do now, but I am running into some trouble.
It seems that Listbox is a friend of Scrollbar, because there is a lot of accessing private members going on. I would suggest that you don't make widgets friends of each other for 2 reasons:

• You will learn of any shortcomings of the public API first hand. This will help you greatly in the design process.
• It will serve as good practical documentation for anyone trying to design their own widgets.

The problems I am having right now is how to do this:

if ((m_Scroll->m_MouseDown) && (m_Scroll->m_MouseDownOnThumb))

This:

m_Scroll->m_MouseHover = false;

And this:

m_Scroll->m_MouseDown = false;

There also seems to be a "using namespace sf" in one of the included files, or maybe a typedef, because I had to add "sf::" in front of every "Vector2f". This is more a question of personal taste I suppose, but I don't think saving a couple of keystrokes is worth losing the extra documentation.

[texus]

Sorry, I completely forgot that it depended so heavily on the scrollbar.

I know I made some pretty bad design decisions in the past, but this is because I never expected to get this far.
I never planned custom objects so a lot of thing had/have to change.

I will make all methods virtual and all private members protected asap.
If this change is not done in the next hour then it means you will have to wait until tomorrow.

[model76]

That is awfully kind of you - thanks!

Don't get me wrong, texus, I am not questioning your abilities or trying to be mean. I know first hand how hard it is to write a GUI library. I rewrote mine from scratch 4 times before finally dropping it - or at least putting it on hold, we'll see.
The tiniest, seemingly insignificant decision can have enormous consequences as the project grows, and I think I finally understand why Laurent sometimes spend months thinking about design before doing anything - even if a solution seems obvious to some.

One thing is for sure: TGUI will make you become a much better coder. If I ever decide to reboot my own project, I will be most fortunate if you take the time to criticize some of my decisions.


/EDIT
About your recent change to Form's constructor

m_Window = &window;

Won't this simply copy the RenderWindow? Shouldn't you be using the initialization list and make m_window a reference?

[texus]

Its done.

I am not really a planner, I usually just start coding and I'll see where it ends. This will hopefully change as I get more experienced.
But the best way to become a better coder is by getting critics. If I wouldn't have put tgui online then I would still be coding like in v0.3, which was a version not really worthy to be released.
But looking at sfml code also helped me a lot.

EDIT:
It will make a pointer to the window, so it isn't copied.
It should be exactly as before, only I will get the pointer inside the constructor instead of letting you pass the pointer to the constructor.

[model76]

I am not really a planner, I usually just start coding and I'll see where it ends.

When Notch was developing Minecraft, the only documents he kept we a list of bugs, and a list of features he wanted to implement, but thought he might forget about. I believe it is called "iterative design" and is all the rage.

Anyway, that is also how I do things, except I start keeping documents as things get complicated. My brain just can't hold that much info at once, I guess. I also use a whiteboard, which I can really recommend!

EDIT:
It will make a pointer to the window, so it isn't copied.
It should be exactly as before, only I will get the pointer inside the constructor instead of letting you pass the pointer to the constructor.

How did I miss that '&'? I must have special powers!

[model76]

As I am looking through the code, I noticed certain things, and have these suggestions:

All the methods that doesn't change any members should be made constant. Examples of this are the getSomeColor methods.
You should generally also make arguments const, unless you have a good reason for not doing so.


Why use this ID system for items? I would simply use their index directly and return an int instead of unsigned int in the getters. '-1' could then be used to indicate failure, which is quite common.
If you want to go the ID route you should implement a true unique ID system, completely decoupled from item index.


Instead of doing this:

/// The string will be empty when the id was too high or when it was 0.
sf::String getItem(unsigned int id);

You could also take a string reference, fill it, and return a bool to indicate success, like so:

bool getItem(const unsigned int id, sf::String &returnValue);

This is a common strategy when you want to return more than one piece of information.

In the constructor of Listbox you have:

m_ObjectType = listbox;

What is the purpose of this? It is never used in the class.


I hope you can use my critique.