Messages

You aren't linking to the tgui library.

Code Select Expand

g++ main.o -o app -L ../TGUI/lib  -L ../SFML/lib -lsfml-graphics -lsfml-window -lsfml-system
should just be

Code Select Expand

g++ main.o -o app -L ../TGUI/lib  -L ../SFML/lib -ltgui -lsfml-graphics -lsfml-window -lsfml-system

I made some changes to the focusing.

- Widget now only has a focus, unfocus and isFocused function.
- Container now have focusPreviousWidget and focusNextWidget functions.
- Container::unfocusAllWidgets was renamed to Container::unfocusWidgets.
- Container::unfocusWidget was removed (use either focusNextWidget or unfocusWidgets depending on what you want to achieve).
- Some fixes in the focusing behaviour.

(Everything said about Container is also true for the Gui class)

I don't think it is a good idea to make the gui handle the view itself. It would be easier in your situation (which is I guess the most common situation of changing the view), but it will limit other possibilities.

By making you set the view yourself, I don't limit your possibilities. You can scale the gui, you can even move the widgets throught the screen without even accessing the widgets. All that by just setting a different view (the view also has to be set while handling events, otherwise it won't work).

If I would automatically make the widgets draw inside your screen, even when the view is changed, then these advanced things with views will no longer be possible. That is why you will always have to set the view yourself, to keep full control on how the gui is drawn.

But i didn't understand what is happens...
And for me it will be good if, then i make gui->draw its draw elements in sf::View rectangle.

I'm having problems understanding your english.
I know that it can be hard, but if you are asking something, could you try to explain it in more words? I really can't make anything from what you said, especially not from the second line.

That's exactly what I meant.
So if that isn't what you were looking for then you will have to describe what you want a little bit better.

If you want to change the view in your game then you will need to work with two views, one for the gui and one for the game.

So you do something like this:
reset the view
draw gui
set view like you want it
draw other stuff

The libraries were rebuild and tested, so if you have the same problem with the new alpha2 libraries then let me know.

I'll remove CloudFlare again, and see if that helps (this can take 4 hours or even longer).

The site is online.

I have visited it multiple times in the last 2 days to check this (because I heard other people saying that it was down a lot), and it was always online when I checked.

Even according to downforeveryoneorjustme.com the site is online.

Not sure why you can't get to it.
The server is located in Netherlands, so maybe thats whats giving troubles. But I use different vpns and proxys, and it was always online for me.

Edit: The latest source can always be downloaded from github.

Maybe you should remove LoadFromFile() from 0.6  code examples meanwhile.

I could do that, but I'm just going to keep it for now. In the end, everything still works except passing callbacks.

The widgets can be given a name so that you can get a pointer to it in the c++ code and add a callback there.
Of course it would be easier if it would be integrated in the widget files, but it isn't completely useless in its current state.

For extra convenience, you could do a focusTop(), focusDown(), focusLeft(), focusRight() in Grid

I don't want to add too many unneeded things to the gui, even if it is more convenient in your situation.
In most cases focusing isn't even used, so I don't think I need so many functions to focus another widget.

Is focusFirstChildWidget() possible?

You could use unfocusAllWidgets followed by focusNextWidget. That should have the same effect.

Maybe also a possibility to disable mouse input to the gui?

Yes but this requires me to add a function to disable the mouse, add a boolean to store the setting, add if statements in the event manager to ignore the mouse, make sure that child widgets also disable their mouse, ...
This isn't a big change, but compared to the fact that it only takes a single if statement on your side, I don't think its worth the effort.

It can't be done. It is a functionality that disappeared when writing the callback system of tgui v0.6.
I am planning to allow it again, but this will require me to manually check every widget agains every different kind of callback that it has, so its a pretty big change (lot of copy pasting though).

I am actually waiting until the new form builder is ready. It will allow me to make a few more simplifications to the loading from file, giving me slightly less work with implementing this. The only problem is that this can still take some time. I really hope to get it finished before september 20th though, afterwards I won't have so much spare time anymore.

Keyboard navigation is basically impossible to do directly in a gui library.
When in the menu, you might want to use the up and down arrow keys to navigate, but in the game the arrow keys shouldn't influence the buttons you have on your screen. So a gui lib can never respond directly to arrow keys, you have to handle everything yourself because you know exactly when everything should happen. But having focusPreviousWidget and focusNextWidget will make it easier to navigate with arrow keys (or game pad).

Together with adding focusPreviousWidget, I'm also going to try to merge EventManager into Container (which I have been planning to do for some time). This means the change will be a little bigger so you can expect it on september 4th or 5th.

Everything seems fine.
It works on linux but I can't test on windows right now.

What you should do is try to rebuild the library because I can not vouch for the stability of the precompiled libraries at this moment.

Could you also include the form.txt file so that I can make sure that the form builder didn't mess something up?

What compiler are u using? (VC++ I guess)
Did you download the precompiled library? (You might want to try to build the library yourself to be sure)

Most likely problem for a crash in Visual Studio is linking debug libraries in release mode (or release libs in debug mode), so make sure this isn't the case.

PS: If the crash is fixed and you want your text in the widgets to show up then you should place the setGlobalFont before your loadWidgetsFromFile function call.