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

[texus]

If you dig deeper into my code I am sure you will find more of these things, but I appreciate the critiques.

The constants are something that I could easily improve.
Changing the ids is a bigger change, but still something I will probably do.

The change in getItem (and other similar functions) might not be made soon.
I believe I made enough api breaking changes in v0.5. It will probably be changed the next time I rewite a big part of my gui.

The m_ObjectType has lost its purpose after the introduction of custom objects. I still keep it in there for 2 reasons: to find out if the object is a radio button (I don't want to add a bool just for that) and for safety on callbacks. It might be a bad habit to do so, but if you want to cast the callback object to a listbox then you might want to make sure that the pointer really points to a listbox and that you didn't accidentally passed the same callback id to e.g. a button.

[TheVirtualDragon]

I am sorry if this question has been asked before, but what features does this library have that make it different from sfgui? Which library should I use?

[model76]

Hi texus,

I found a bug that would sometimes make item text in a Listbox appear blurry.
I fixed it by changing 2 lines in the draw method:

states.transform.translate(2, (static_cast<float>(static_cast<int>((i * m_ItemHeight) - m_Scroll->getValue()) + ((m_ItemHeight / 2.0f) - (bounds.height / 2.0f) - bounds.top))));

to

states.transform.translate(2.f, static_cast<float>(i * m_ItemHeight) - static_cast<float>(m_Scroll->getValue()));

and

states.transform.translate(2, (i * m_ItemHeight) + ((m_ItemHeight / 2.0f) - (bounds.height / 2.0f) - bounds.top));

to

states.transform.translate(2.f, static_cast<float>(i * m_ItemHeight));

TheVirtualDragon, I am in the process of evaluating both libraries, and here are my thoughts so far:

SFGUI is a really well thought out library, designed by a team of experienced coders. Unfortunately, it is no where near complete, and has many bugs. Its design makes the learning curve a little steep, certainly for newbie coders, and especially concerning its system for automatic widget positioning. If you want to fundamentally change the look of the widgets, you will also have to write your own rendering engine.

TGUI is designed by a single coder, and from looking at the code, it is clear that he wasn't very experienced when he started. The design is, shall we say, minimal. However, from what I have gathered, texus' skills, and thus the quality of his code, is quickly improving. In contrast to SFGUI, TGUI's widgets are purely drawn with sprites, and that makes changing their looks very accessible.
Please keep in mind that I have only been looking at how to style widgets, design a new one, and display them on screen. I haven't even looked at handling state changes, button clicks, etc. in TGUI.

One thing the libraries have in common is that their developers are doing a great job at supporting their users. Messages are answered quickly, and bugs are fixed promptly.

So in conclusion, which one to use depends entirely on you, what you want to do, and your level of expertise. But why not try both? They are completely free you know, and not just for evaluation purposes!

[texus]

I cannot tell you which is better because I have never used sfgui.
I would say it depends a little bit on your personal preference and the only persons who can really give you a good answer to your question are those who have used both tgui and sfgui.

For the bug, it is something that I have seen before, but I ignored it.
The text is drawn at a float position and the scaling done to it doesn't do any good to it either.
So in most objects the text will sometimes appear blurry, depending of the text.

I haven't been able to solve it as it seemed to completely depend on the text. But I must admit that I never really tried very hard to solve it. If your solution works then I will add it to the code and I will look at the other objects as well, but this problem will have to changed object by object.

[model76]

The text is drawn at a float position and the scaling done to it doesn't do any good to it either.
So in most objects the text will sometimes appear blurry, depending of the text.

Since the values the item's positions are based on are all integers, the positions you will end up with wil all be "something point zero". If it were a problem, you could always do this:

std::floorf( floatValue + .5f )

Anyway, your mention of scaling made me try setScale, and the text at least now renders equally blurry on all the list items, unlike before.

But then I stumbled on another couple of bugs:
If you scale a Listbox, the hit boxes on the items no longer fit the graphics.
Also, if you scale down, long strings will display outside the Listbox.

What scaling were you talking about? The text in an unscaled Listbox appears nice and sharp for me with the patch.

[texus]

I wasn't just talking about listboxes, but about all objects. Buttons for instance can auto-scale the text to fit into the button, but this will make it a lot more blurry then with a fixed size. But these are all things that I wrote some time ago and I should review them and see what I can change.

The text in the listbox looks sharp to me even without the patch.
I think it is all about the combination of font, text size and the text string.
So I will have to do some more tests before I implement the patch.

There is one simple rule in tgui right now: never call setScale, always use setSize.
I used to support setScale, but after many changes some of the objects didn't work properly anymore and I haven't had the time to fix it. I am not planning to supporting setScale, just to break the support the next day when I make a change to the object.

I think listbox is the only object were I literally decided to write code that didn't check the scaling of the object and thus won't draw correctly with setScale. ListBox and ComboBox should never be scaled if you want to keep everything working.

This is all going to be fixed before v1.0, but you can (and you should) use setSize, so I don't really see it as a big issue.

[model76]

Yeah, I was actually about to suggest that you simply removed setScale, as I didn't seem very useful to me. But then I thought you might have some reason not to, and decided not to mention it.

But I will make this suggestion, then: Just remove the auto scaling of text from the system entirely. I seems like a wasps nest to me, and something better left to the end user. Most good graphical designs use at most a couple of different font sizes anyway.

I also noticed the naming inconsistency in Listbox and EditBox. How about changing to ListBox?

Also, is it possible to change text alignment in the EditBox? I would really like that feature...

[texus]

I can't remove setScale unless I would create my own Transformable class. And the effects of setScale and setSize won't always be the same so it might still be handy in some situations. Try scaling a panel or a child window, you will see the difference.

Scaling texts is used in multiple places so removing it would not be something I would do right away.

When I created the listbox I noticed that it was spelled differently at different places. I couldn't find out if it was listbox or list box, and eventually I chose for listbox. It could be changed, but I won't do that just based on one opinion.

Why would you need alignment in edit box?
If you have a good reason (which you probably have, otherwise you wouldn't be asking) then I will try to implement it. EditBox should be completely rewritten anyway. The clipping method isn't as good as the one from the later objects.

[model76]

I found another bug. (sorry)

This code:

tgui::EditBox *myEditBox = gui.add<tgui::EditBox>( "myEditBox" );
myEditBox->load( "TGUI/objects/EditBox/Black" );
myEditBox->setSize( 400.f, 18.f );
std::cout << "Width: " << myEditBox->getSize().x << " Height: " << myEditBox->getSize().y << std::endl;

Outputs

Width: 120 Height: 40

I can't remove setScale unless I would create my own Transformable class. And the effects of setScale and setSize won't always be the same so it might still be handy in some situations. Try scaling a panel or a child window, you will see the difference.

I am not suggesting that you don't use some class internally, only that you don't expose methods in the public API that doesn't make sense, or as in this case, specifically should not be used.

When I created the listbox I noticed that it was spelled differently at different places. I couldn't find out if it was listbox or list box, and eventually I chose for listbox. It could be changed, but I won't do that just based on one opinion.

Well, the free dictionary doesn't list listbox as an English word: http://www.tfd.com/Listbox
The built-in spell check in Firefox agrees.

Why would you need alignment in edit box?
If you have a good reason (which you probably have, otherwise you wouldn't be asking) then I will try to implement it. EditBox should be completely rewritten anyway. The clipping method isn't as good as the one from the later objects.

Currently I need center-aligned text to fit in a graphical design that needs it. It does so because, compared to the window size, the widgets are few and spread out. Centered at the top of the screen is an EditBox that ties the whole design together. If the text is aligned left or right, the whole design will 'tilt' to one side.

Right alignment is useful for presenting numbers vertically. Just think of a spread sheet. In this case, right alignment will make it much easier to compare the size of the numbers.

[texus]

I found another bug.

It isn't a bug, but it is something I am planning to change.
You should use getScaledSize, because getSize returns the size of the original image (which has a height of 40).
I am planning to remove getSize in the future and rename getScaledSize to getSize, but until that moment you will just have to type a few more characters every time you want to know the size of an object.

only that you don't expose methods in the public API

As far as I know, there is no way to simply hide the function as it is public in sfml.
I keep the setScale function working for as much objects as possible though. Simple objects like pictures, labels, buttons and edit boxes can perfectly use it.
I was just using the scaling in a wrong way in ListBox and calculations became too dificult and confusing. I have learned my lesson and when I reimplement scaling in ListBox, it will work better than before.

the free dictionary doesn't list listbox as an English word

Thats of course more convincing. I'll see if I can change it tomorrow.
I don't know why I picked Listbox. If I just look at google now I almost always see ListBox.

Right alignment is useful for presenting numbers vertically.

Right alignment for numbers makes sense. And adding center alignment would be a small extra.
I can't put a date on this though. Maybe tomorrow, maybe next week. I'll see about it.

[model76]

As far as I know, there is no way to simply hide the function as it is public in sfml.

You could overwrite it with a private or protected one. It is a bit of a hack, though.
If a class inherits one or more methods that doesn't make sense, then it shouldn't have an is a relation ship with that other class.

If that is something that pops up in your code, it is an indicator that you should probably start thinking about your inheritance scheme.

[texus]

There is nothing wrong with my inheritence scheme (at least not if it comes to sf::Transformable).
But you did make me realize that I should do something. I can't be left like this.

If I can't fix it before tomorrow evening then I will indeed have to override the functions as private until the scaling problems are solved.

[model76]

I have started playing with the "callback" system, and have some notes:

First of all, when I think of a callback system, I think of a system where you can register a callback function. I would describe what TGUI has as a type of event system. This is a little confusing, and I would personally rename it.

I am also having trouble seeing how I could separate out which events were handled by TGUI, and which ones I should let my own code handle. Example:

Let's say I have a system that responds to mouse down events. I also have a TGUI button. How can I tell if a mouse down event happened on the button or not? If it did, I don't want to also handle it in my own code.
The tgui:Button only seems to respond to click events, and I would need at least an isMouseOnWidget method, or a mouse down event.

[TheVirtualDragon]

Thanks for the info, I think I will use TGUI as I am making a quick map editor which doesn't really need many widgets.

[texus]

I'll think about the renaming.
Before the first public release, there was a real callback system but it wasn't good enough so I made this event system.
It is something that I have been thinking of rewriting again, so if you have ideas on how to improve it then please let me know.

I am afraid that there is no mouse down event. You will only receive click events.
I don't want to overload the program with callback events that aren't needed in most situations.

You could always call mouseOnObject to see if the mouse is on top of the button at the time the mouse went down. But you would have to do that for all objects so that isn't really a solutions.

But why would you need to know when the mouse went down on a button? Why can't u just wait to do something until the user really clicked on the button?

I am making a quick map editor which doesn't really need many widgets

It depends on what kind of map editor and how you are going to do it.
You could create a map editor with just tgui. If you have a tilemap then you could use SpriteSheet objects, you can draw all images with Picture and all texts with Label, ...
It has the big advantage that your drawing loop exists of only the drawGUI call at any time. You no longer have to to use bools to decide when to draw what as everything is made visible or invisible before and with just one draw call u can draw everything.
The amount of widgets u use depends completely on how you are going to write it, not on the kind of program.