Messages

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?

Glad to see that TGUI is used in a ludum dare by other people than myself .

The game looks good, well done!

If you would like to make tutorials then that would be very kind.

Maybe the most important one right now would be a tutorial about how to configure visual studio to use the library. So if you want to do something you could perhaps make a few screenshots that fit these instructions.

Other than that, I'll put any helpful tutorial online.

But maybe the tutorials shouldn't be placed on my site, but on the github wiki? That way everybody could just add useful tutorials.

For now, I'll let addLine return the numbers of lines.

The other option is better, but requires a bit more work (e.g. make sure that a newline in a label has the same spacing as the lines that I manually place below each other).
I'll implement it somewhere soon, but for now you'll have to do with the first option.

Edit:
With the Notepad++ way, what do you expect that happens when the string that you pass to addLine has a '\n' character? Should it count as two lines or should everything passed to addLine count as a single line?
I'm thinking of something like skype. In your message you could still add newlines, and it would be nice that the whole message could be treated as a whole. But on the other hand, it also makes sence that when encountering a newline means that the lines are split.

The three functions have been added.

I could add the following functions:

Code (cpp) Select Expand

sf::String getLine(unsigned int lineNumber);
void removeLine(unsigned int lineNumber);

Maybe I should add this as well?

Code (cpp) Select Expand

void setLineLimit(unsigned int maxLines);

But the right click is a bigger change. I was trying to delay that until I was going to add a PopupMenu widget (probably not in v0.6).