SFGUI (0.4.0 released)

[Oliveira]

Nice

Thanks a lot !

[Turbine]

A work around with that whole dragging a window outside the window is only running sfgui update if the mouse position is not outside the window. Better than either the window disappearing or freezing the game right?

[torey0]

I've been having trouble setting up a project to use SFGUI. Pretty noobish to C++ but not other languages so I'm missing the linking part.

Using VS2012 I can setup a project that will show the hello world SFML example. Got it separate for debug and release, and I have it statically linked as that's the only way I could get it to work. That all works fine.

Then I can add onto the project and add in the include, lib, and static directive for the SFGUI files. Eventually I got these to work fine and can do an #include <SFGUI/SFGUI.hpp> or whichever the one that loads everything was. The project still runs since the code didn't actually use any SFGUI.

But then if I change the code to use an SFGUI window too, I can't get it to work anymore. It ends up not being able to find the .lib files that the SFML is already able to find. The only thing that worked for me was manually putting the 14 .dll files from SFML and SFGUI into the folder that the .exe will be saved in, and also putting the sfml-system.lib from my original SFML download into the SFML that is included with your download. Leaving anything set to the static libs like I had it with just SFML and no SFGUI would not resolve...

So in summary, I can get it to work finally by just using all dynamic linking and copying over some missing files. So as a noob to C++ what am I missing here that would let me just easily do static linking like my SFML project before I add SFGUI?

[binary1248]

You know that the different link options produce library files with different suffixes right? -s -d -s-d

Also you shouldn't rely on moving files around. Just set up the search paths inside and outside of VS2012 to point to the correct locations and you shouldn't need 2 copies of SFML. SFGUI will use the one it can find, which should also be the one you use in your projects. If you are unsure what library files you are using or where they are, just delete all of them and try building something simple. Once you can't build any more, they should be all gone. After that, build SFML once and make sure to not copy the library files. Do the same for SFGUI and you should prevent any strange version mismatch errors from occurring in the future.

[torey0]

I did have the suffixes right in the linker input. And the include and lib folders were added into the include and library directories for the project respectively. Those steps came straight from the tutorials so I have triple checked them. Googling sfgui visual studio didn't turn up much for me.

I wouldn't want to be copying files around anyway, but the SFGUI's SFML lib folder is missing 2 files, and when I left it set to static linking it couldn't resolve some external call (with the -s in all the file names in the linker and the preprocessor directives working, since that worked with SFML alone), and I guess I'm ignorant as to how to get the .dll files it then needs as it dynamically links in the same folder as the .exe I am using. That actually reminds me, none of the example .exe's run unless I copy all those .dll's into the example folder, so those weren't made static for some reason either?

Trying to use the right terms here, hope I've gotten my questions across. Thanks for responding to someone just looking to get into more C++.

[binary1248]

http://sfgui.sfml-dev.de/forum/topic216-compiling-static-library-from-cmakevs2012.html

Tank "broke" static linking in the hope that SFML would fix the link procedure on its side in foreseeable time. I guess it hasn't come to that yet . I guess for now, you need to manually force CMake to use a static SFML (add SFML_STATIC to the defines and link to static SFML libs) when building SFGUI. Blame someone... just not me .

[torey0]

So for a more proper setup I guess I'll have to learn about CMake and building stuff myself. Thanks for your advice, hopefully I didn't come across too hostile 

[FRex]

You've been publicly criticized, congrats:
http://www.gamedev.net/blog/1682/entry-2256533-most-gui-libraries-are-terrible/
 

[binary1248]

At least what was said is all true. We are aware of these issues and it's not like progress isn't being made . If you want a fully functional GUI library that is well-documented don't use SFGUI, at least for now. One of the reasons we couldn't offer support for Aaron is because he is trying to build on a Mac, and none of us have a Mac, so obviously it is going to be difficult finding out what is going on...

And for the record... the GLEW problem is not our fault... it's Laurent's ^^. We just inherited the trouble from SFML .

[FRex]

I agree with him, Qt is some sort of a joke, it takes almost 2 GB when installed and visual 10 can't parse it's headers because it's so huge so you can as well code in gVim(Hi tank). Also Qt Creator on windows hanged up on me badly and was unkillable. This is massacre. It's really not fit for anything game related, I wanted to code my editor in it, dropped the idea soon after, I'm taking SFG over anything.

CEGUI - Heavy/Intimidating at first but feature rich, documented and proven in many games.

SFGUI - Tank is MIA, sfg::ListBox is MIA, Bob renderer is MIA and I swear that your documentation is some form of psychological warfare.

libRocket - Seems dead, who knows what is going on, I too was surprised about how out of date it's front page is.

[binary1248]

libRocket - I scared Tank off from using it any more by showing him the asm code they embedded into their source, link here.

CEGUI - I used to use this, also tried out FLTK and GLUI. CEGUI seemed the most complete albeit far from optimal/elegant. I guess people use it because it is the lesser of all evils and basically gets things done cheap and fast.

Qt - What? Only 2GB? I think I remembered Qt taking at least 4GB on my system. After I was done with the depender, I got rid of it. Qt is like the Windows of GUIs. It comes with everything you can possibly need, and even more that you won't. The sad part is that although you can shrink it down, it isn't worth the effort and you end up just riding it through, much like Windows.

SFGUI - Tank is on indefinite vacation or something, sfg::ListBox Tank still holds a lock on this task last I remember (or want to imagine ), Bob renderer is.... no idea, progress was being made then we changed the backend a bit, added a few more widgets and Bob ran away never to be seen again, not even a code snapshot..., and yes our documentation is psychological warfare, meant to deter those who dare consider using CEGUI or filling half their hard disk with development libraries .

[Tank]

SFGUI 0.1.1 has been released!

0.1.1 is mostly a bugfix release which is now officially compatible to SFML 2.1.

Changelog

Enhancements:

• Compatibility to SFML 2.1.
• Reimplemented sfg::Canvas.
• Rewrote sfg::Renderer::Display() interface to allow sf::Windows to be used as targets for GUI rendering as well.
• Added support for multiple pages in the texture atlas to support arbitrarily many images and image sizes (that themselves would fit on the GPU of course)
• Added PackStart, PackEnd and ReorderChild to Box to make using it easier.

Fixes:

• Made sure to restore coherency between wiped states cache and OpenGL texture binding by unbinding any bound textures after wiping the cache.
• Moved spinner RenderQueue update logic into Engine-side code to decouple the Widget from it's Engine implementation and make it easier for custom Engines to be written for it.
• Changed CMakeLists.txt to accept SFML 2.x instead of only 2.0.
• Fixed hiding ACTIVE widgets getting them stuck in ACTIVE state, blocking all future events from reaching other widgets.
• Fixed appending and prepending text to an Entry not properly invalidating it.
• Fixed removing child from table not removing associated cell entry.
• Changed found message type in FindSFGUI.cmake to STATUS to prevent people from being unnecessarily surprised when something worked. #636
• Fixed clicking on combobox drop-down menu causing window reordering when the menu reached over the edge of the parent window onto another window. The Desktop now only considers reordering when there is no modal widget active. #628
• Fixed Window not properly ignoring invalid mouse move values. #607
• Fixed m_parent_notified being uninitialised on first use in Widget. #638
• Added missing "out of window" check when handling MouseMove events in sfg::Scale.
• Fixed not taking into account padding when determining if the Renderer needs to create a new atlas page.
• Fixed child widgets not notifying tentative parents of the child's invalidation if the invalidation took place before it was added to the parent and the next update cycle.
• Added explicit sf::Context construction before querying GLee for supported extensions to fix special cases where no sf::Context is available yet thus making GLee report wrong extension information.
• Fixed broken behavior when removing a page from a Notebook, now warns when trying to remove the last page of the notebook

Download

Downloads and other information can be found on the official website.

Kudos!

...go out to binary1248 for fixing all the glitches and reworking some parts of the library and eXpl0it3r for being the build slave again.

[Kojay]

Good to see binary hasn't been left struggling all by himself 

Needless to say, I think the new Canvas is what everyone looking for separate drawing areas was wishing for.
Is there any chance we will see it behave more like an sfml window, such as using sf::Views on it, or getting local mouse coordinates (getAbsolutePosition() isn't enough by itself for the latter).

[binary1248]

Is there any chance we will see it behave more like an sfml window, such as using sf::Views on it

Render whatever you want to your own sf::RenderTexture and render that on an sf::Sprite onto the sfg::Canvas. Many layers but it gives you ultimate flexibility.

or getting local mouse coordinates (getAbsolutePosition() isn't enough by itself for the latter).

You have the position of the sfg::Canvas relative to the origin of the SFML window and you can get the position of the mouse cursor relative to the origin of the SFML window... I don't see how you can't find the position of the mouse relative to the origin of the sfg::Canvas with that information...

[Kojay]

I can, but it means the class I built around the canvas needs to keep a reference to the big window the canvas is in. Ok no big deal, but otherwise the class doesn't care at all about big window.