SFGUI (0.4.0 released)

[ChronicRat]

I commented one line in CMakeLists.txt:

# Find packages.
find_package( OpenGL REQUIRED )
#find_package( SFML 2.1 REQUIRED COMPONENTS GRAPHICS WINDOW SYSTEM )
 

I have not found another solution. After creating the project files need a little correct them manually.

[eXpl0it3r]

I have not found another solution. After creating the project files need a little correct them manually.

No idea what you're talking about, but if you prevent the SFGUI CMake script from finding SFML, you'll have problems building SFGUI, since it depends on SFML...

[binary1248]

Try one of these:
git clone git://boxbox.org/SFGUI-binary1248.git -b testing
https://github.com/binary1248/SFGUI/tree/testing

I changed the CMake configuration a bit to make it easier to understand what is asked of you. And setting SFML_ROOT (either as an environment variable or in CMake) is all that is required to get a working SFGUI build configuration.

A word of warning though: Due to a limitation of CMake, if you want to link SFML statically, you need to delete it's library entries and let CMake search for the static ones again. It won't change the paths unless they don't previously exist. Would be nice if Laurent could think of a solution to this . Maybe an SFMLConfig.cmake or sfml-config.cmake?

[Laurent]

Maybe an SFMLConfig.cmake or sfml-config.cmake?

Where is the pull request?

[Tank]

SFGUI 0.2.0 released

Version 0.2.0 of SFGUI has just been released. Changes include:

Enhancements:

• Conversion of codebase to use C++11 features.
• Implemented two backend renderers (one uses vertex buffer objects, the other client-side vertex arrays).
• Generalized renderer textured quad creation from CreateImage into CreateSprite allowing Engine developers more freedom to manage resources and convey their usage.
• Allow creation of RadioButtonGroups in advance.

Fixes:

• Fixed linking and general building errors on OSX.
• Fixed corner case bug with canvas.
• Fixed viewports not propagating properly.
• Fixed index count not being reduced in renderer when primitives are removed.
• Fixed FindSFGUI.cmake ignoring standard arguments.
• Removed obsolete UpdateViewRect() from sfg::Desktop.
• Fixed renderer crashing when drawing without any textures loaded into the atlas.
• Fixed loading fonts in renderer.
• Adapted CMake configuration to the new SFML linking system.
• Got rid of SFML as an extlib (Git submodule).
• Cleaned up CMake configuration file.

WEBSITE http://sfgui.sfml-dev.de/

[eXpl0it3r]

HAX!

You forgot one point: Made a nicer website.

[Tank]

Thanks.

[FRex]

Conversion of codebase to use C++11 features.

I swear to God I was going to troll about that on your forum. I even had it in my TODO list:

sfg cus its 2013 and they still dont use std::function or shared ptr

That and one other usability defect that I won't yet say what it was, but I think that fixes it:

Implemented two backend renderers (one uses vertex buffer objects, the other client-side vertex arrays).

I'm going to check it out now.

[Nexus]

Hey, that website background is stolen from me

Cool to see SFGUI being actively developed! I think you once discussed that, do you still plan to move SFGUI away from SFML in the long term? Did you ever consider making it compatible with other graphics libraries, such as Irrlicht or OGRE?

[eXpl0it3r]

Hey, that website background is stolen from me

Did you say something? I only hear NOISE.

I think you once discussed that, do you still plan to move SFGUI away from SFML in the long term? Did you ever consider making it compatible with other graphics libraries, such as Irrlicht or OGRE?

As by the FAQ and the various discussions on IRC, that seems to be the goal, but I rather let the master(s) speak.

[Tank]

Did you say something? I only hear NOISE.

It indeed looks like yours. However it's just the GIMP noise filter to make the background less boring.

I think you once discussed that, do you still plan to move SFGUI away from SFML in the long term?

Yes, absolutely, SFGUI will be completely decoupled from SFML. We will initially provide drivers for using SFGUI together with SFML and raw OpenGL applications/games. With some effort it should be possible to use SFGUI with OGRE and Irrlicht as well, then (of course only if the OpenGL drivers are used, DX is not and will never be supported).

[FRex]

What about making it so that SFG doesn't use much(or any) globals and sfg::Desktop or sfg::SFGUI is 100% self contained so that weird problems like I-removed-widget-from-desktop-but-it-still-renders and i-want-to-have-few-guis-in-one-app are solved?

[Tank]

What about making it so that SFG doesn't use much(or any) globals and sfg::Desktop or sfg::SFGUI is 100% self contained so that weird problems like I-removed-widget-from-desktop-but-it-still-renders and i-want-to-have-few-guis-in-one-app are solved?

Widgets that are removed from desktop but still render is not related to globals at all. A widget you hold a reference to will itself hold a reference to its visual render object. That's why you still see it even if it's removed from the widget graph. It's a behavior that I don't like as well, but changing that will also introduce a big change of the underlying memory model, i.e. how widgets are managed. It's something that can't be done in a couple of days.

I don't understand your second issue.

[FRex]

I don't understand your second issue.

    The desktop manages stackable children and manages an own rendering engine.

    The desktop should be use as a managing class for all your windows/widgets. Set your properties here so that your children refresh automagically.

http://sfgui.sfml-dev.de/forum/post1199.html#p1199
This in docs, this quote from binary, and the fact that code that has two desktops will render both on Display() suggest that it's not so supported to have few independent interfaces in one app(such as few windows, or , after you divorce with SFML - a 3D app with pcs/interactive surfaces/menus/hud, all independent of each other) unless you explicitly iterate aaaallllllll widgets in the world and call Show(false) on them while also calling Show(true) on all of the ones you want to render...

[Tank]

You don't have to iterate all widgets, you can hide parent widgets easily. It's a problem if multiple instances of sfg::Desktop don't work, but using one of it shouldn't be a big deal.