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.

Maybe I should explain a bit how I got to the current design (of which parts still date back from the first release).
I had a bit of a problem with hover and focused images in the past. If those would be two different images, which one would you display when the button is both focused and hovered? At that time, both hover and focus images were transparent and drawn on top of the normal image, so that it looked good. Later I decided that hover images shouldn't always be transparent and I added a SeparateHoverImage image flag to control whether or no the hover image was drawn on top of the normal image or it would be a seperate image. Focus image however remained being drawn on top of the hover image to avoid the question of which of the two should be visible.

And then the part why there isn't a focused image in the black style.
Although tgui supports using the tab key to focus the next widget, tgui aims mostly on games. So this is a very unneeded possibility. Because in games you normally don't need a focused image (with what you are doing now as an exception), the focused images were removed from the default styles.

What you want to do, is make a copy of the Black.conf file and add the following lines to the Button section:

Code Select Expand

FocusedImage_L = "Black.png" (  0, 175,  50, 50)
FocusedImage_M = "Black.png" ( 50, 175, 100, 50)
FocusedImage_R = "Black.png" (150, 175,  50, 50)
And then load your edited version instead of Black.conf.

That will give the buttons back their focus images, allows them to be focused again, and will most likely solve #14 that you just created on github.

Edit: I should have noticed this earlier, but I must have missed the link that we were talking about focusing stuff while focus images were removed in the default style.

By default Black is the only config file. But you can always create your own config files.
And the widget files are just text files, so the config file can always be changed later and you could just use Black as temporary images in the form builder.

But there are a lot of things that could be improved in the form builder. Auto-saving would be one of them, although that wasn't on the list of changes that I was going to make.

Gui is a special case. It is only not inheriting from Container (anymore) because it solves other design problems. Whatever gets added to Container will also be added to Gui, so you don't have to worry about Gui not having those functions.

I just tested navigation with keyboard and noticed that the hover image does not get used when a widget is focused.

The focus image is drawn on top of the normal and hover ones, so if your focus image isn't transparent then you won't see the hover image. Or are u using the Black style?

How can I manually set a widget as "being hovered on"?

You normally don't do this, so there is no function to do so. You could always call the mouseMoved function with mouse coordinates that lie on top of the widget, but this will be undone when then moving the mouse again. Basically you just aren't supposed to do this.

What would happen if there is no next or previous widget?

I think it is most logical that the widget stays focused and nothing changes (Currently the widget gets unfocused).

So even after the main window is no longer overlapping with the others, you can't move the other windows?

I'll compile the form builder again with sfml 2.0 and then I'll send you the executable.

Was the forum/tgui.eu/tgui.net down for a while?

Not that I know, but it can always happen from time to time.

Edit:
I've uploaded a working form builder.

I currently don't have much time, but such function could indeed by handy so I'll add it soon (within a week or so).

It will require me to write some extra code, because the focusNextWidget was actually pretty simple. It just calls the unfocus function of the parent, knowing that that will lead to the next widget being focused. A focusPreviousWidget function would have to really look for the right widget to focus.

When I add the function I will also make another change. I don't think focusNextWidget should be in Widget, so I'll probably move it to Container and then add the focusPreviousWidget to Container (so you call gui.focusNextWidget()).

That is indeed a good use case.

But the change is pretty big (and I haven't decided yet if I really will implement it), so you can't expect it anywhere soon.

I guess you will to draw the 9 images and the text on top of it yourself with sfml for now.

Is it possible to define several buttons? From the .conf I got the idea that there was only one button.

The config file can only contain one button, but you can use different config files (e.g. a different config file for different resolutions).

I don't think having different Button sizes is an outlandish idea.

True, I am using it as an example but I realize that you normally don't do that.

I'd use it

The question is why?
If you could give me something that you could do then that you can't do already, then I might be more likely to consider the idea.
But knowing how much more complicated some parts of my code are already due to SplitImage, I won't be convinced very easily.

I don't think this is needed.

SplitImage was made mainly to make the default tgui styles look good for any application, so that it still looks nice when using them as temporary images or even as permanent images.

The idea is that when making your own images, you will make them have the correct size and you wouldn't need SplitImage. When you want to support multiple resolutions you could also have multiple images if you can't get the wanted result with SplitImage.

I think it would make my code unnecessary more complicated if I would implement what you are proposing.
I have thought about this myself before, but I still don't have a really good reason to make my SplitImage code harder than it already is.

I know it is easy to overlook, but it's in the tutorial.

When using TGUI v0.6, make sure to check the "-std=c++0x" or "-std=c++11" compiler flag.

If it is missing from the VS binaries then that is a mistake. I'll fix that soon.

There is a bug in SFML 2.1 that is really annoying, and is causing the problems for the form builder.
You should be able to click on the title bar of the big window and move it away. Then when the windows are no longer overlapping you should be able to move the other windows after clicking on the title bar.
It should become usable when the windows are no longer overlapping.

Or is it even worse than that and can't you really move anything?

Edit:
I just downloaded the pre-compiled VS2012 libraries and it contains a form-builder directory with a FormBuilder.exe.
Did you download the v0.6-alpha1 from the download page?