Messages

You should use a different view for sfml and tgui if you want to render them differently. Because you want the gui view to change with the resolution, you can't just pass true to the draw function (which is for changing sfml view while keeping the gui view).

So you will have to do something like this:
    set sfml view
    render with sfml

    set view for tgui
    render the gui

How to change the view is something that is explained in the sfml tutorials.

~15% of the fonts i tested (around 20) didn't work, would be interessting to know why 

Ok, I'll try to figure out if it has anything to do with tgui next week.

But anyways thanks for the great gui and good luck with you exam tomorrow!

Thanks

Little spoiler

Looks good.
I played Kroniax some time ago when it was still new, I guess I should look at it again because a lot seems to have changed since then.

Strange. If I run your code on my pc, then everything looks fine. The only change I made was use the DejaVuSans.ttf which is provided in tgui.

I can't really do much now. I got an exam tomorrow and the day after tomorrow and two more next week.
But afterwards I'll definately look into this in more detail (check on windows with the libraries that I uploaded instead of just testing on linux with some unknown tgui version installed).

I can't immediately reproduce this.
Could you send me the widgets file (the file created by the form builder) and a minimal code example?

The form builder is still far from being complete and some things just don't work like they should. It is possible to add the lines in the form builder, but it requires a specific syntax. You can always write a small c++ code and call gui.saveWidgetsToFile to see what the values of some properties should be.
If you would want to specify the lines directly in the form builder then you would have to set the Lines property to "(Line1\, (255\, 0\, 0)), (Line2\, (0\, 255\, 0)" (without the quotes). But I'm aware that is a pain to write it that way.

You should take a look here: https://tgui.eu/tutorials/v06/config-files/.

You should just try to have a look at the existing styles and try to learn how it workes by just changing some parameters and look at the results. But feel free to ask if you have a more specific question.

If I understand the question correctly then this is indeed about a basic part of c++.

With some basic type:

Code (c++) Select Expand

int i1 = 0; // Create an integer
int* p = &i1; // Create a pointer with the address of i1
int i2 = *p; // Dereference the pointer (get the value of i1)

You are in the exact same situation as the last line, you need a RenderWindow while you only have a RenderWindow* (just like you needed an int and had an int*).
So you can just initialize the gui like this:

Code (c++) Select Expand

tgui::Gui gui(*renderWindowPointer);

There is something wrong with the dlls.

I removed the dlls from your Release folder, and replaced them with the onces that you send earlier, and then everything worked fine.

I'm getting a http error 500 on that page.

Edit: I can acces it now

I just tested your libraries and I don't have any problem with them.

Do you have vs2010 sp1 installed?

Could you send me your vcxproj file, and create a minimal example code (so that we test with the exact same code)?

I would guess something like that from the "Error: Modules with different CPU types were found." line.

All libraries do need to be build for the same architecture.

Which generator did you select in CMake when building TGUI?

I never had the problem myself so I don't really know what you could do.

Quickly googling for that error tells me that you might need to set /OPT:NOREF in linker optimzation settings.

I'm going to sleep now, and tomorrow I have an exam, but I can try to take a look at it afterwards. So if the above doesn't fix the problem and you are 100% sure that you are linking correctly then put your sfml and tgui libs somewere (e.g. dropbox) and I'll see if I can find something special about them tomorrow.

I would guess that your SFML and TGUI libraries aren't compatibe.

Both should be compiled for your exact compiler. Did you compile tgui yourself? You'll have to because there are no precompiled libs for VS2010 (yet).

Both libs should be linked in the same way. In a debug build, you need the debug libs and in release you will need the release libs. If sfml is static, then tgui has to be static as well (or both dynamic).

You could disable it, which will stop the events from reaching the text box.

Code (c++) Select Expand

textbox->disable();

However if you do this then the scrollbar won't work anymore.

So I would suggest using the ChatBox widget to create a log panel.

There might be a bug in the clang compiler.

https://stackoverflow.com/questions/20927695/clang-bug-with-stdfunction-stdbind-and-stdref

Thanks.

On mac I tend to not use the resourcePath() like the sfml examples but to just put this at the beginning of the file:

Code (c++) Select Expand

#ifdef __APPLE__
    #include "CoreFoundation/CoreFoundation.h"

    CFBundleRef mainBundle = CFBundleGetMainBundle();
    CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
    char path[PATH_MAX];
    if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
        return 1;

    CFRelease(resourcesURL);

    chdir(path);
#endif

But using resource paths will probably make it easier either way, and could also be used for other things. So I'll definately include this in the v0.6.0 release.

Could you try changing the std::ref to std::cref and see it the error still occurs?

I hope that it can get solved like that, because I really don't have much time right now (I have exams this month).

Are you using the Github sources as SFML_ROOT or are you building then installing SFML and using that as your SFML_ROOT? For me, cmake complains about missing files if it SFML_ROOT is set to the Github sources.

I just wanted to respond on that you said that FindSFML.cmake was the only file in that folder. I pointed to the contents of that folder in the latest sfml version to show that there should be multiple files. I didn't do anything, I haven't even opened cmake today .

But anyway, I have now applied the patch in the master branch. So everything should work now without changes.
Thanks for your help.

But I think other people might still have problems with this. I think that it finds the dependencies because you install sfml. I don't install sfml which might explain why it didn't found the dependencies for me yesterday. But the automatically finding isn't really a big issue, especially because you shouldn't be building the form builder on windows in the first place. And at least I can just tell people to just try to install sfml.
And with a little luck, I just did something wrong yesterday, and it will just work out-of-the-box.

FindSFML.cmake is the only file in the SFML/cmake/Modules folder.

I use this as a reference: https://github.com/LaurentGomila/SFML/tree/master/cmake/Modules

Copying it to the the TGUI/cmake/Modules folder allows cmake to find the the required dependencies and everything builds as it should.

Really? When I tried that then cmake complained that it couldn't find the dependencies and I had to set them manually. I'm not sure what we are doing differently. Anyway, I guess I can already safely update the FindSFML.cmake script in tgui without breaking anything new.

If you copy FindSFML.cmake from the SFML install location to the TGUI cmake/Modules it will build properly. If you're using cmake-gui, you can also manually set CMAKE_MODULE_PATH to the SFML/cmake/Modules path and it will build successfully too, since it winds up pointing to the same file.

I wasn't talking about just FindSFML.cmake, I was talking about the other files. I am trying to understand what I have to do to make cmake find the dependencies to jpeg, glew and freetype automatically.
The questions basically are:
- Does cmake find these dependencies automatically without changing the settings? (apparently not)
- Does cmake find them when setting CMAKE_MODULE_PATH to the sfml folder?
- If the above question is yes, is it enough to copy ALL the files from SFML/cmake/Modules to TGUI/cmake/Modules and then just leave CMAKE_MODULE_PATH to its default value?

I like the second option because of its simplicity for the user, on Windows at least.

Well, once this problem is solved, the necessary files will be in TGUI/cmake/Modules by default and you don't even have to change the CMAKE_MODULE_PATH option or copy any files at all.

As for building on my own, I want to make sure I want to make sure I'm using the most up to date version of SFML with the form builder since it's also being used in my game. It's one less thing to think about.

Building the form builder against SFML 2.0 or against the github version of sfml isn't going to make any difference at all. It only makes a difference with which tgui version it is compiled, and the current form builder is only a few commits behind.
If you use the latest sfml version then you will of course need to compile tgui against this latest version, but recompiling the form builder isn't needed.

If you want, I can look into making the install process how I was requesting.

That would be really kind. You probably have more experience with developing on windows than me, so maybe you can make it work.

To simplify matters, in cmake-gui you can set CMAKE_MODULE_PATH to "SFML-Location/cmake/Modules" and as far as I can tell everything still builds and compiles like it should.

So if you just copy all the files from there into the TGUI/cmake/Modules and you build it with the current settings then it all works without manually setting the dependencies locations? Or do I really have to set it to the sfml folder?
(sorry for all these questions, I can't test it myself right now)

Would you be willing to add the formBuilder to the install process so that the executable and related files go to ${CMAKE_INSTALL_PREFIX}/formbuilder? I'm on Windows, so this doesn't happen automatically for me.

I once did but it didn't went well.
In visual studio I never got it working, I didn't know how to tell it to install it instead of just compiling it. This problem can be worked around though if I would tell in the tutorial to compile with NMake Makefiles instead of letting you create a visual studio project (because then I can tell to run 'nmake install').
In codeblocks you had to just change the target from 'all' to 'install' (which seemed to work for some time), but I started getting privilage problems later (it tried to install to Program Files and it failed).
I'd like to install it to the correct folder, but it would take a lot of work and time. And I don't have much time these days and I hate working on windows, so this doesn't seem like something that I will do very soon.

But why do you really need to build the latest version? The reason that I ship tgui with an already working windows executable is because I know that it is hard to compile it decently on windows.

Thats fine. You can send it to texus@tgui.eu.

I like these.
I prefer the one with the slightly smaller box, could you perhaps upload the psd file for this one?

I'd like some more opinions though. Especially about what colors to use, whether or not to underline the text, ...
I'm going to make a post on the tgui blog in the hope to draw some more people to this topic and get more input.

You've already helped out a lot, thanks.

This looks like a good starting point for a logo.

The thing that I want to change the most is the lack of a check, the empty box doesn't has much meaning (if you wouldn't know that it is a checkbox then you wouldn't recognise it).
But maybe we should experiment with a RadioButton instead? That way the check is just a circle inside the bigger circle button.

You don't have to keep so strict about what I said about 'simple'. I think the most important thing is that the logo is recognisable, not ugly, and if possible still has something to do with the gui.
So feel free to experiment with whatever ideas you have.

Edit: I have made the logo on the forum random until a more permanent logo has been found. If other logos are suggested then they might also be added to the list of possible displayed logos.
Caching might interfere with the randomness though.

I think I found a fix, but I need you to comfirm that it is working (I have dozens of tgui and sfml versions on my pc for various compilers, so it is easy for me to make a small mistake and point to the wrong directory).

First of all, you will need to copy the file SFML/cmake/Modules/FindSFML.cmake to TGUI/cmake/Modules (overwrite the file in there so that it becomes the latest version).

Then in TGUI/src/TGUI/FormBuilder/CMakeLists.txt copy the following code to line 17 (right after linking to sfml and tgui)

Code Select Expand

# When linking statically, also link the sfml dependencies
if (SFML_STATIC_LIBRARIES)
    target_link_libraries(FormBuilder ${SFML_GRAPHICS_DEPENDENCIES} ${SFML_WINDOW_DEPENDENCIES} ${SFML_SYSTEM_DEPENDENCIES})
endif()

Can you confirm that this solves the problem?
I had to set the location of the dependencies manually in cmake (they are in SFML/extlibs), so I still have to find a way to make cmake look there automatically. But I first want to make sure that it works for you too before making more changes to the cmake script.

By the way, when building the form builder yourself on windows it will be placed in TGUI/build/src/TGUI/FormBuilder, so don't forget to replace the one in TGUI/form-builder with this executable or you will still be using the older version.