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

[texus]

I think you are pointing to the wrong MinGW folder. When I start CMake it automatically finds the folder "C:\MinGW" which was the default location when I installed it with CodeBlocks. The folder that u use also exists on my computer, but it is not used in any CMake options.

I think it is strange that CMake doesn't find this folder automatically. I had a similar problem some time ago and I solved it by reinstalling CodeBlocks. After that it compiled without any problems.

[Laurent]

C:/PROGRA~2/CODEBL~1/MinGW/bin is not a valid make program (CMAKE_MAKE_PROGRAM). Did you change it? It should normally be "C:/Program Files (x86)/CodeBlocks/MinGW/bin/mingw32-make.exe".

And you should avoid spaces in your toolchain paths, make/gcc don't like them.

[Khaos]

I installed a stand alone version of MinGW and that worked with CMake. I assume it was because my MinGW was located in C:\MinGW.

Now when I try to build the project (install) I get this.

-------------- Build: install in tgui ---------------

Using makefile: Makefile
Execution of 'make.exe -s -f Makefile install' in 'C:\sfml\TGUI\build' failed.
Nothing to be done.

At least I made progress. Where should I proceed from here? Thanks.

[texus]

I am afraid that all I can do is guess right now.
I have tested it multiple times and I never had any problem, so I never experienced your situation.
I think it was even tested on an empty windows, just the codeblocks install with mingw and for the rest nothing installed.

You could try using the 'all' configuration, the only difference is that my Form Builder and the tgui.dll won't be copied to the correct directory.

The only difference I see now is that you have 'make.exe', while in my log it sais "Running command: C:/MinGW/bin/mingw32-make.exe -f "E:/Documents/TGUI/build/Win32_CodeBlocks/Makefile"  VERBOSE=1 install".
So either you find a setting in codeblocks to change from make to mingw32-make or you will have to run it from the command prompt.

The only reason why I don't use the command prompt in the tutorials is because it might be to difficult for beginners. But you could take a look at the sfml tutorial and try the steps from there. U will have to generate 'MinGW makefiles' (not the CodeBlocks ones) and build it yourself from the command prompt with mingw32-make.

[Ruckamongus]

Hey Texus,

I don't know how easily it could be implemented, but is it possible to have animated interfaces? For example, the button could have multiple "mouse over" and "mouse leave" subimages. Mousing over a button could have 5 subimages that fade dark, etc.

[texus]

It should be possible, I just don't have the time for it right now. But I'll definitely consider it before the final release of v0.5.

[Khaos]

find a setting in codeblocks to change from make to mingw32-make

This worked!

ok, now I think we are down to the last problem. I assume this is because of the SFML version I am using.

'BackSpace' is not a member of 'sf::Keyboard'|

I am using SFML 2.0 RC. Should I change these lines to anything?

EDIT: Changed all instances of BackSpace to Back and it compiled! I think I can finally get it up and running.

Thanks a bunch!

[texus]

I got a few design questions for those who are using my gui (or anyone else who wants to give his opinion).

First of all, objects can be focused. This means that you can use the tab key to focus another object. Is this really necessary? I don't really see many use cases for focusing objects. Does anyone really needs this? Removing this focussing will not only spare me the work of adding it to the objects that don't have it yet, but it will also open other possibilities (e.g. adding a tab character in a text box). On the other hand, you will no longer be able to focus a button and press enter or space to trigger it.

Secondly, something has to happen with selecting text in edit boxes and text boxes. Currently you can have text selected in multiple edit boxes at the same time. This shouldn't be to hard to solve, but it brings up a question. Is it necessary that when you click outside the edit box, the text stays selected? Currently the text will get deselected anyway when clicking back into the edit box. It would even save another color if it would get deselected right away when clicking on another object.

Let me know what you think about it.

[eXpl0it3r]

Although I'm not using TGUI, I'll still give you my feedback. I mean the questions aren't that specific to TGUI.

This means that you can use the tab key to focus another object. Is this really necessary?

I think this depends heavily on the use cases of TGUI. For GUI applications, removing that feature would be a big no-go. Take for example a login dialog with a username and a password text field and a button. Would you really like to select the first text field, enter the name, then grab the mouse again, then enter the password, grab the mouse again and click 'login', or wouldn't you much rather, enter name, tab, enter password, tab, enter?
On the other hand, when you use TGUI for a game I guess it wouldn't really matter, since you most probably will have your mouse in your hand anyways, then again there could still be some use cases.
My opionion: Don't remove it!

but it will also open other possibilities (e.g. adding a tab character in a text box).

I'm not sure how you handel textboxes at the moment, but normally for GUIs one makes a difference between textarea boxes with multiple lines and a one liner textbox. For a one liner textbox it usually doesn't make sense to allow tabs (tabs are there for formatting, what would one want to format in one line) but they can make sense in a textarea. Now there are diffrent situations where one wants to allow tabs in textarea fields and one maybe doesn't, so a switch that lets the programmer use tab in one or the other way would kind of solve that problem.

Secondly, something has to happen with selecting text in edit boxes and text boxes. Currently you can have text selected in multiple edit boxes at the same time. This shouldn't be to hard to solve, but it brings up a question. Is it necessary that when you click outside the edit box, the text stays selected? Currently the text will get deselected anyway when clicking back into the edit box. It would even save another color if it would get deselected right away when clicking on another object.

Both possibilites exist in other GUIs, so I guess it also depends a bit on the kind of application. If you make something in the direction of a text editor losing the selection can be quite annoying, for other uses IMHO it doesn't really matter. Since the selection gets lost anyway I'd say you can automatically deselect it (or does it stay selected when 'tabbing' the the textbox?

[texus]

Thanks for your feedback.

You are right about the use in a login screen, so I should indeed put an option somewhere to enable/disable the use of the tab key. Then you could add tabs in a (multiline) text box, depending on this option. If tabbing between objects is disabled then you will be able to use tab chars, otherwise not.

I don't think anyone is going to write a text editor with my gui so if it doesn't really matter otherwise then it might be better to just drop the selection. Then you no longer have to provide an extra color for when the textbox is unfocused and it will have some impact on speed as well. If I would keep the selection then I would have to loop through all my objects every time I make a selection, just to make sure that no other edit box has something selected.

Tabbing back to the edit box keeps the selection and it should have been kept too when clicking back on the edit box, but the text gets unselected by a small bug. Normally I would just fix it, but just deselecting the text when focusing another object seems to have it advantages.

[Senzin]

Hi Texus, I just wanted to alert you to what I think is a bug in your CMake script.

I followed your instructions for setting up with the CMake GUI. I pointed SFMLDIR to ".../SFML/SFML-2.0" and SFML_INCLUDE_DIR to ".../SFML/SFLM-2.0/include". The obj files compiled fine, but I got tons of linker errors all complaining about sfml. This happened with both NMake and VS 2008.

After some investigating, I noticed that in project settings in VS 2008, the Linker/Input was pointing to ".../SFML/SFML-1.6/[libs]". That just happens to be where I keep my 1.6 version. I double checked several times with CMake and tried recreating everything to make sure I wasn't pointing CMake to the wrong folder, but it kept trying to use the 1.6 libs.

Finally I just moved every folder inside ".../SFML/" other than the SFML-2.0 folder somewhere else and tried again. This time it worked. So that's really strange. Somehow the presence of the SFML-1.6 folder makes the generated scripts point to those libs.

[Senzin]

Hi Texus, I'm having problems with the Form Builder. Strangely, it will only show objects that are in the bottom left of the window (see attachment).

As you can see, there is an obvious rectangle of space at the bottom left where objects show up, but anything outside that space does not. You can clearly see objects being cutoff at the edge of the space. If I create a new object, the properties window will update with the new object's information, but I won't be able to see it at the top left. But I can click on it and drag it to the bottom left where it will show up.

Notice also the Fraps fps numbers in the four corners of the window. The frame rate is around 19-20 fps. You can see it at 19 in the bottom left. However in the other three corners, you see the numbers "19" and "20" pasted on top of each other, never clearing. And in case you didn't know, Fraps only puts the fps in one corner at a time.

Clearly something is wrong here. I've tested TGUI in my own programs and have found no such problems.

SFML2 and TGUI were both built from freshly downloaded src today (8/1/2012).

I've attached the FormBuilder.exe file (see attached rar) so you can test it yourself. Could you possibly send me a working copy of the exe?

[attachment deleted by admin]

[texus]

About the CMake problem, I won't be able to do much about it. The script clearly looks for version 2.0, so I don't know why it wouldn't work. But thanks for reporting, if someone has a similar problem in the future then I at least know how to solve it.

There have been some strange rendering problems in the form builder before, but I think all problems should be solved now in the latest commit of v0.5.
You can find the executable that I compiled here, it is compiled with this latest version, so it should work.
I can't test it on windows right now, but the exe seems to run perfectly on linux through wine.

I couldn't test your version as it was build dynamically and I couldn't find the corresponding dlls (I have too many different versions on my pc).

[pighead10]

Sorry for taking so long to point this out after the last view bug - I was on holiday The objects will only work correctly with Views if you set the view after the object is created. I set the view then create all the objects but change the view when the window is resized, which means in order to use the GUIs I have to resize my window.

[texus]

I don't have any problems with using a view, neither in v0.4 or v0.5.
A lot more testing happened in v0.5 so you might want to try that version though.

If you still have problems then could you please post some code to be sure that we are testing the same thing?