SFML community forums

General => SFML projects => Topic started by: Tank on October 17, 2011, 05:36:34 pm

Title: SFGUI (0.4.0 released)
Post by: Tank on October 17, 2011, 05:36:34 pm
SFGUI is a GUI (Graphical User Interface) C++ library especially designed for programs and games that use SFML for rendering.


The library has been designed with flexibility and performance in mind. Several features get you started really quick and make using the library easy: The automatic layout takes care of positioning and sizing widgets properly. Even if you have to deal with different screen resolutions, SFGUI will always try to pick the best layout.

Included are a lot of widgets, like buttons, toggle buttons, check buttons, radio buttons, drop down boxes, entries, scrollbars and some more. At any time you can extend the library by custom widgets.

The widgets' visuals are completely separated from their implementations. SFGUI makes use of so called "widget rendering engines" to create the visuals. One engine is included in the release, called BREW, which uses simple shapes and solid colors to paint the widgets. The shapes, colors, fonts etc. can be modified by setting style properties, which can be done directly in C++ or by loading external theme files, which look similar to CSS.


Features

Download
Download from here (https://github.com/TankOs/SFGUI/releases).

Contact
Website: https://github.com/TankOs/SFGUI/wiki (https://github.com/TankOs/SFGUI/wiki)
Title: SFGUI
Post by: Nexus on October 17, 2011, 07:57:56 pm
Good to hear of SFGUI again!

I have downloaded the Git version a few days ago, and from what I've seen until now, its features as well as the code look very nice!

A minor issue: Compile times are relatively high, I think you could reduce them by using less #includes. For example, Button only depends on sf::String by name (i.e. forward declaration is enough). If you wrote shared_ptr<Label> instead of Label::Ptr, you could also remove the Label dependency. You already got rid of two #include directives, even without the use of Pimpl ;)

By the way, I recently came across Header Hero (http://altdevblogaday.com/2011/10/08/caring-by-sharing-header-hero/), a nice tool to find dependency bottlenecks.
Title: SFGUI
Post by: Tank on October 17, 2011, 09:41:35 pm
Thanks for your reply. I'm glad you like it. You're well-known as a superb C++ guy, so I'm kinda proud you like the code design. ;-)

You're absolutely right about the compile times. I already have a local Git branch where I try to get rid of includes just to reach typedefs. Using shared_ptr directly is a good solution, unfortunately it appears as such in the docs. Not a big deal, but I'd prefer the consistent "Ptr"/"PtrConst" style. In terms of effectivity it's no real option.

Thanks for the Header Hero hint, haven't read about it before and going to check it out. Also thanks for your GitHub issue contrib, solved a build issue. ;-)
Title: SFGUI
Post by: OniLinkPlus on October 18, 2011, 12:10:20 am
Quote from: "Tank"
Thanks for the Header Hero hint, haven't read about it before and going to check it out. Also thanks for your GitHub issue contrib, solved a build issue. ;-)
Header Hero just came out a few days ago, so it makes sense you never heard of it.
Title: SFGUI
Post by: Tank on October 18, 2011, 12:43:42 am
Unfortunately it doesn't run on Linux. :( I'll see if it will by installing all those .NET stuff in Wine.
Title: SFGUI
Post by: OniLinkPlus on October 18, 2011, 12:51:09 am
Quote from: "Tank"
Unfortunately it doesn't run on Linux. :( I'll see if it will by installing all those .NET stuff in Wine.
It's .NET, so it should. It's VERY useful. Cut down my total header size (counting includes) by >50%
Title: SFGUI
Post by: victorlevasseur on October 19, 2011, 11:32:25 am
Quote from: "victorlevasseur"
Hello,

I recently discover SFGUI : it's a good GUI library for SFML.

I am going to use your library to create a plug-in for a french game creation freeware (Game Develop) (this freeware uses SFML for render). The plug-in will not use the layout widgets, but only the widgets like buttons, entry, scale...
I'm just waiting the developper of Game Develop to add a functionnality that allows plug-ins to access to the list of events produced by PollEvent.
Then, I will begin the plug-in developpment.

Where can I find the SFGUI logo ?
And can I use widgets without any container ?

(Sorry, if I make some english mistakes, I am only 16 and I'm French)


I have to use widgets separatly because the freeware (Game Develop) use an "object" concept. So I will create a Entry Object, a Button Object...
Title: SFGUI
Post by: Tank on October 19, 2011, 12:31:47 pm
Quote from: "victorlevasseur"
I have to use widgets separatly because the freeware (Game Develop) use an "object" concept. So I will create a Entry Object, a Button Object...

I think I got it now. So by container you don't mean widget containers like the layouters in SFGUI, but managing classes, right?

If so: Widgets are created directly in SFGUI, so it should be fine for your game development tool.
Title: SFGUI
Post by: victorlevasseur on October 19, 2011, 12:40:43 pm
Not exactly, GD (Game Develop) allows the user to create objects which are placed on a scene by him with absolute positions.

Game Develop is not my software, it is developped by Florian Rival (4ian) : http://www.en.compilgames.net/?file=kop1.php for further informations
Title: SFGUI
Post by: Tank on October 19, 2011, 01:06:55 pm
Well, you can place a layouter at an absolute position and let it handle the rest. ;)
Title: SFGUI
Post by: victorlevasseur on October 19, 2011, 04:16:14 pm
I don't know how to explain that.
For example, this software is provided with Sprite object, Text Object, Light Object and many over. So I create other kinds of objects using SFGUI. The user can only place them himself, they cannot be placed by others objects.

If you want, I can show you what my future plug-in will do in the software.  :wink: (I just wait for 1 week : the new version of Game Develop)

You show a picture of the window drawn by the Bob Render Engine. Where is Bob ?
Title: SFGUI
Post by: Tank on October 19, 2011, 07:49:55 pm
Let's do an example:
Say you have "Box" (a layouter) and "Button" exported to Game Develop. Then you create a Box object and a Button object. If Game Develop is able to call something on objects, you can pack the button into the box. If not, then you really must use completely separated widgets. :)

Bob has not yet been applied to the master branch. You can check the current state here: https://github.com/Iteem/SFGUI/tree/Bob
Title: SFGUI
Post by: victorlevasseur on October 19, 2011, 08:15:52 pm
Quote from: "Tank"
Say you have "Box" (a layouter) and "Button" exported to Game Develop. Then you create a Box object and a Button object. If Game Develop is able to call something on objects, you can pack the button into the box. If not, then you really must use completely separated widgets. Smile

Yes, but I don't think it was really user friendly (the users of Game Develop don't know programmation and the use of layouts). But, i will certainly add this later.

Quote
Bob has not yet been applied to the master branch. You can check the current state here: https://github.com/Iteem/SFGUI/tree/Bob

It's strange, it doesn't appear in the TankOs/SFGUI branches list.
Title: SFGUI
Post by: Tank on October 20, 2011, 04:22:51 pm
Quote
It's strange, it doesn't appear in the TankOs/SFGUI branches list.

Yep, it's not maintained by me, but by a guy called Iteem. Just follow the link, you can clone it then. Or you go with the default rendering engine "BREW" as long as Bob is not applied to the master branch (you don't need to do anything to "activate" it; it's there by default).
Title: SFGUI
Post by: Tank on October 20, 2011, 04:40:17 pm
*** Update ***

The new properties system has just been applied to SFGUI's mainline. Some flaws are still present (not all widgets are 100% compatible), but in general it works very good and convenient. ;)

So, what's the new property system all about?

Previously you were able to set widget properties in the rendering engine AND in each widget. This was not acceptable, because properties only affect rendering in the most cases, so there's no reason to store them in widgets.

Also it was not possible to select special widgets for custom properties very easily. SFGUI lacked a nice selection feature. That's now included.

Imagine you want to change the text color of a label that's on a button. You do:

Code: [Select]
SetProperty<sf::Color>( "Button > Label", "Color", sf::Color::Red )

Those who wrote/read CSS will like the syntax of the selector. ;)

Widgets can now also be identified by IDs and classes. Say we have a special quit button that we want to style differenty:

Code: [Select]
SetProperty<sf::Color>( "Button#quit", "BackgroundColor", sf::Color::Black );
SetProperty<sf::Color>( "Button#quit > Label", "Color", sf::Color::Red );

SetProperty<sf::Color>( "Button#quit:Prelight", "BackgroundColor", sf::Color::White );
SetProperty<sf::Color>( "Button#quit:Prelight > Label", "Color", sf::Color::Black );


Those 4 lines do the following:


Those rules can be applied to all available widgets. Btw., the "prelight state" is usually the state when the user moves his mouse pointer over the proper widget.

Here's a screenshot (using BREW as the rendering engine):
(https://dl.dropbox.com/s/hjcz0ep75738rlp/sfgui/sfgui_prop_brew.png)
Title: SFGUI
Post by: Laurent on October 20, 2011, 05:07:14 pm
I'm not familiar with SFGUI so excuse me if I'm totally wrong :)

This system looks nice, but how does it work if I want to style the widget that I just instanciated?
Do I have to assign my widget a unique ID (what if I'm in a loop that creates many instances?) so that I can call SetProperty? Or if it already has an ID, do I have to retrieve it, concatenate it to the class name, and pass it to SetProperty? In other words, is there an equivalent to SetProperty that takes a pointer to a widget instance instead of a string selector?

And why do you need to explicitely write the type of the template parameter? Can't it be deduced from the third argument?
Title: SFGUI
Post by: Tank on October 20, 2011, 05:58:25 pm
Quote
Do I have to assign my widget a unique ID (what if I'm in a loop that creates many instances?) so that I can call SetProperty?

In such cases you probably want to style all those widgets in the same way. That's what classes are for:

Code: [Select]
for widget in all_my_widgets {
  widget.SetClass( "fancy" );
}
...
SetProperty( ".fancy", "Color", sf::Color::Red );

(the "." is the syntax for specifying a class)

Note that the widget's name is also not required! That should answer your second question. :) If you leave anything out, it's like placing a "*" wildcard:



There's no version of giving a pointer to SetProperty(). It's possible and there's already a method to build a widget's complete path with all attributes in a widget tree. But I think it's just not needed. It's probably easier to give IDs and select by IDs. This will also get more important when loading GUI descriptions from markup files (like XML).

Quote
And why do you need to explicitely write the type of the template parameter? Can't it be deduced from the third argument?

It can, however it's not possible for types that'd be converted implicitly, like int -> short. Properties are stored as boost::any, and types of new properties are always checked against the needed type. I haven't found a way yet to allow shorts for an int property. :)
That's why you should always specify the template parameter, to make sure.
Title: SFGUI
Post by: victorlevasseur on October 20, 2011, 06:49:23 pm
I downloaded the new update and it compiles with a lot of warnings like that :
Quote
veloppement\GD2\GDLSDK\ExtLibs\boost\boost\signals2\detail\preprocessed_arg_type_template.hpp|21|warning: invoking macro BOOST_SIGNALS2_PREFIXED_ARGS_TEMPLATE_DECL argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98|
Title: SFGUI
Post by: Tank on October 20, 2011, 07:19:55 pm
What compiler are you using?
Title: SFGUI
Post by: victorlevasseur on October 20, 2011, 07:23:59 pm
I use MinGW 4.5.2.
This warnings are produced many, many, many times with all files.

And It produced some errors.

EDIT : If I don't build the example, there are no errors, it compiles with a lot of warning but it works perfectly.  :shock:
Title: SFGUI
Post by: Tank on October 20, 2011, 09:09:23 pm
I use G++ 4.5.2 here (too) and don't get any warnings. Without further investigation I assume it's not triggered by SFGUI code, but a warning in the Boost header. I see if I can find some info on that.

UPDATE
Boost.Any has been removed from SFGUI. That means easier usage of SetProperty (like critized by Laurent). Because of the change the hardcoded property value types got completely removed. Every type can now be used by providing operator<< and operator>>.

For conversions Boost's lexical_cast is used.

The change will be applied to master soon together with the last missing property name corrections needed due to the system change.
Title: SFGUI
Post by: victorlevasseur on October 20, 2011, 09:28:31 pm
Thanks, I use Boost 1.46.1 for information.
But, SFGUI compiles and functions correctly.
Title: SFGUI
Post by: Tank on October 20, 2011, 10:52:15 pm
Same Boost version over here. Are you on a Linux system?
Title: SFGUI
Post by: victorlevasseur on October 21, 2011, 07:06:09 am
No, I compile on a Windows system.
Title: SFGUI
Post by: Tank on October 24, 2011, 02:07:01 pm
Sorry, don't have a clue yet what goes "wrong". Let's see if there are/will be other Windows users using MinGW running into the same problems. One contributor however is also using MinGW (in Code::Blocks) on Windows and doesn't get any warnings.
Title: SFGUI
Post by: victorlevasseur on October 26, 2011, 08:36:59 pm
Is multi-character selection planned for sfg::Entry ?
Title: SFGUI
Post by: Tank on October 27, 2011, 09:52:37 am
Not yet, may change in the future, but I think not for a first release.
Title: SFGUI
Post by: Tank on October 30, 2011, 07:34:46 am
Update

We're working on getting rid of Boost.Signals2 by implementing our own signalling system using fast delegates (http://www.codeproject.com/KB/cpp/FastDelegate.aspx).

Benefits are:

Another good news is that if you're using a compiler supporting C++11/0x (and you also use the new standard in your projects -- which most using MSVC 2010 do by default), you can get rid of the Boost dependency completely. Changes will be pushed into master the next days.

binary1248 completed a first draft of a CSS-like theme loader that utilizes Boost.Spirit for the parser element. It's opt-in so you don't have to use it. The code is not yet implemented in master but can be reviewed and tested in binary1248's fork on GitHub (check the network feature at SFGUI's GitHub page to find it).
Title: SFGUI
Post by: Naufr4g0 on October 30, 2011, 07:46:10 pm
I'd like to try SFGUI for a project, but I can''t compile the library.
The issue is CMake-related, cause it can't found SFML_dir and Boost_dir.
How can I manually add the libraries paths in cmake?
Thanks in advance. :)
Title: SFGUI
Post by: Tank on October 30, 2011, 08:26:56 pm
Set SFMLDIR to your SFML directory and BOOST_ROOT to your Boost directory (pay attention at the error messages the search modules give, they normally tell you what variables can be set to use custom search paths).
Title: SFGUI
Post by: Naufr4g0 on October 30, 2011, 08:46:20 pm
Quote from: "Tank"
Set SFMLDIR to your SFML directory and BOOST_ROOT to your Boost directory (pay attention at the error messages the search modules give, they normally tell you what variables can be set to use custom search paths).


I tried a lot of combinations, but CMake says me it can't found the libraries!
What files CMake expects to find in SFML and BOOST DIR? .cmake files or .h and .cpp?
Forgive my ignorance on CMake. :'D
Title: SFGUI
Post by: Tank on October 30, 2011, 08:51:31 pm
The paths must be set to the root directories of the libraries respectively.

E.g. if you've installed SFML to C:\SFML\, set it to that directory. Same for Boost. For Boost you only need the include directory, since SFGUI doesn't use any compiled libraries.
Title: SFGUI
Post by: Naufr4g0 on October 30, 2011, 09:37:50 pm
Quote from: "Tank"
The paths must be set to the root directories of the libraries respectively.

E.g. if you've installed SFML to C:\SFML\, set it to that directory. Same for Boost. For Boost you only need the include directory, since SFGUI doesn't use any compiled libraries.


Still doesn't work. I'm sure I put the correct folder paths.
May perhaps be because I use the gui version of cmake?
Title: SFGUI
Post by: asdatapel on October 30, 2011, 11:34:20 pm
So how do i set the paths? do i do it on the command line with cmake or something?
Title: SFGUI
Post by: thePyro_13 on October 31, 2011, 03:19:25 am
You can use the GUI cmake to set them, you may have to create the variable youself.

The directory you set them to is the same as the install directory you set when configuring cmake for sfml.
Title: SFGUI
Post by: binary1248 on October 31, 2011, 04:19:49 am
For those who still can't figure out how to use CMake on Windows:

{SFML root directory} is the directory with the SFML source. (I don't like to install libs all over my system so the source copy is good enough.)

[list=1]
Name: CMAKE_MODULE_PATH
Type: PATH
Value: {SFML root directory}\cmake\Modules (The directory where FindSFML.cmake is.)


The SFML_xxx_LIBRARY_yyy-NOTFOUND entries should be the compiled SFML library files themselves. (Not the directories they are in!)
The SFML_INCLUDE_DIR-NOTFOUND should be the directory where the SFML includes can be found: {SFML root directory}\include
If you compiled SFML with only 1 build type then select the same library file for both debug and release.
You do NOT have to fill in the SFML_DIR entry if the others are present.

Title: SFGUI
Post by: keyforge on October 31, 2011, 02:17:53 pm
Thanks, binary! I got it working. I'm not very experienced with CMake and that was a good tutorial (the most I've done is compiled SFML 2!).
Title: SFGUI
Post by: Naufr4g0 on October 31, 2011, 02:41:16 pm
Thanks for the tutorial Binary! Very well done! :)
Unfortunately I've another error.
CMake can't still find the SFML library. :(

(http://i44.tinypic.com/9t33g8.png)

Quote from: "keyforge"
Thanks, binary! I got it working. I'm not very experienced with CMake and that was a good tutorial (the most I've done is compiled SFML 2!).


Did you modified some cmake file to make it working?
Title: SFGUI
Post by: Tank on October 31, 2011, 05:40:27 pm
Did you try setting SFMLDIR to "C:/sfml/sfml2/"?
Title: SFGUI
Post by: asdatapel on October 31, 2011, 06:40:33 pm
god i hate cmake. Is it possible for you to just put up the compiled binaries, like on the download page for sfml?
Title: SFGUI
Post by: Naufr4g0 on October 31, 2011, 07:30:24 pm
Quote from: "Tank"
Did you try setting SFMLDIR to "C:/sfml/sfml2/"?

I already tried it, but it doesn't work. :/

Quote from: "asdatapel"
god i hate cmake. Is it possible for you to just put up the compiled binaries, like on the download page for sfml?


I'm interested too. I use Visual Studio 2010. :)
Title: SFGUI
Post by: Tank on October 31, 2011, 07:50:51 pm
Sorry guys, but SFGUI is in heavy development. Maybe it will later be possible to provide nightly/weekly builds, but it just doesn't make sense right now, as too many things change (especially the API).

I don't like CMake that much, too, but compared to many other build tools it's at least portable to a certain degree. ;) If you know other interesting and working tools, let me now.
Title: SFGUI
Post by: binary1248 on October 31, 2011, 08:56:41 pm
Quote from: "Naufr4g0"
Thanks for the tutorial Binary! Very well done! :)
Unfortunately I've another error.
CMake can't still find the SFML library. :(


"CMake Error at {SFML root directory}/cmake/Modules/FindSFML.cmake ..." is an expected error message after step 9. Proceed with step 10.

If you check the Advanced box as per step 6. you should see the entries you have to modify in step 10.
Title: SFGUI
Post by: Naufr4g0 on October 31, 2011, 09:30:01 pm
Quote from: "binary1248"

"CMake Error at {SFML root directory}/cmake/Modules/FindSFML.cmake ..." is an expected error message after step 9. Proceed with step 10.

If you check the Advanced box as per step 6. you should see the entries you have to modify in step 10.


THANKS VEEEERYYYYYY MUCH!
I put all paths manually and I finally made it! :)
Now I can compile! :)
Title: SFGUI
Post by: Laurent on October 31, 2011, 10:58:21 pm
This is so complicated...

Even if you didn't install SFML, you just have to copy FindSFML.cmake to <cmake install>/share/cmake-2.8/Modules, then set the SFMLDIR variable to the root of the "include" and "lib" directories of SFML, and magically, "Configure" works the very first time you click it ;)

Even better: set it as an environment variable, and you don't even have to do it everytime you configure a CMake project that uses SFML.
Title: SFGUI
Post by: binary1248 on November 01, 2011, 01:28:55 am
Quote from: "Laurent"
This is so complicated...

Even if you didn't install SFML, you just have to copy FindSFML.cmake to <cmake install>/share/cmake-2.8/Modules, then set the SFMLDIR variable to the root of the "include" and "lib" directories of SFML, and magically, "Configure" works the very first time you click it ;)

Even better: set it as an environment variable, and you don't even have to do it everytime you configure a CMake project that uses SFML.


AFAIR I tried setting the environment variable but it didn't work for me. Maybe I did something wrong, but instead of trying to figure out why it didn't work I figured just spend 2 mins more and do it by hand as described above and it'll work. On my Linux system this was all over in 3 commands of course ^^. The people who say Linux is harder to use than Windows definitely have to try out CMake.
Title: SFGUI
Post by: Laurent on November 01, 2011, 09:16:34 am
Quote
AFAIR I tried setting the environment variable but it didn't work for me.

If SFMLDIR (not SFML_DIR) defines a path that has "include/SFML/Config.hpp" and "lib/<sfml libs>", it must work. Unless there's something weird in SFGUI configuration files ;)
Title: SFGUI
Post by: Tank on November 01, 2011, 01:05:37 pm
This is everything SFGUI does to look for SFML: https://github.com/TankOs/SFGUI/blob/master/CMakeLists.txt#L9
Should be the preferred way of doing it.

Maybe the problem was that some of the guys here didn't install the library, but just built in. In that case FindSFML.cmake doesn't find the libraries because they're in the cache directory only. Headers of course are still found.

This all will get easier for some people when there will be a binary release of SFML 2, lol.
Title: SFGUI
Post by: victorlevasseur on November 01, 2011, 01:23:26 pm
You've made a small mistake (not in Cmake), you wrote "Boost 1.45" ont the first page of this topic but the CmakeList need Boost 1.46.  :wink:
Title: SFGUI
Post by: keyforge on November 01, 2011, 05:20:58 pm
I have an issue with building the project created by CMake. It says that it can't find boost/signals2.hpp, yet the file exists in the boost directory.

I'm also interested in the VC++ 2010 binaries!
Title: SFGUI
Post by: victorlevasseur on November 01, 2011, 05:39:31 pm
Have you correctly set the boost directory in cmake ?
You have to set it to the root folder of Boost (not the "boost" include sub-folder)
Title: SFGUI
Post by: Naufr4g0 on November 01, 2011, 05:51:30 pm
I solved CMake-related issue with SFGUI, but now I have some VS2010-related issues.. :/

Code: [Select]

error C2059: syntax error: '__declspec(dllexport)' C:\libs\SFGUI\include\SFGUI\Engine.hpp 15 1 sfgui


Incriminated lines are this (from Engine.hpp):

Code: [Select]

namespace sf {
std::ostream& SFGUI_API operator<<( std::ostream& stream, const Color& color );
std::istream& SFGUI_API operator>>( std::istream& stream, Color& color );
}
Title: SFGUI
Post by: Tank on November 01, 2011, 06:05:19 pm
For those having still issues with setting up CMake: Read the FAQ (http://sfgui.sfml-dev.de/faq#cmake_find). You'll find solutions to the most common pitfalls there.

@Naufr4g0:
This is a known issue and has been fixed in another branch. I've cherry-picked the fix and applied it to master. So please pull the latest commits from the Git repository and rebuild, should work then.
Title: SFGUI
Post by: keyforge on November 01, 2011, 06:16:59 pm
Quote from: "victorlevasseur"
Have you correctly set the boost directory in cmake ?
You have to set it to the root folder of Boost (not the "boost" include sub-folder)


Yes, Boost_INCLUDE_DIR is set to C:/Library/boost_1_46_0/
Title: SFGUI
Post by: Tank on November 01, 2011, 06:30:48 pm
@keyforge:
(I was wrong, removed the assumption ;)). Please consult the FAQ, it explains how it's done right.
Title: SFGUI
Post by: Naufr4g0 on November 01, 2011, 11:08:12 pm
I finally managed to make SFGUI to work.
I have successfully started the test project on VS2010. :)
Title: SFGUI
Post by: Tank on November 02, 2011, 10:20:34 am
Very good! What helped you in solving your issues? (so that we can adjust the FAQ if others run into the same problems)

Question to everybody:
I'd like to know how many of you use C++11-supporting compilers? I've recently removed the complete Boost dependency by replacing several sub-systems with either our own ones or using C++11 features.

AFAIK MSVC supports at least TR1 beginning from MSVC 2008 SP1 and GCC beginning from version version 4.

If you want to test it, please give this a shot: c++11 branch @ GitHub (https://github.com/TankOs/SFGUI/tree/c++11) (download as ZIP (https://github.com/TankOs/SFGUI/zipball/c++11)).

Important: The branch also includes the upcoming signalling system replacement and other optimizations, so if you have already used SFGUI in your projects, then builds will be definitely broken without adjustments. I suggest to build SFGUI and the test application in order to see if your compiler supports the code.

Would love to hear from results. :-)
Title: SFGUI
Post by: Naufr4g0 on November 02, 2011, 11:35:31 am
Quote from: "Tank"
Very good! What helped you in solving your issues? (so that we can adjust the FAQ if others run into the same problems)


I solved with the following CMake settings:

SFML 2.0
(http://dl.dropbox.com/u/4564869/Screenshots/CMake_sfml.png)

and unchecked BUILD_SHARED_LIBS.

SFGUI
(http://dl.dropbox.com/u/4564869/Screenshots/CMake_sfgui.png)

and additionally I set this variable, as suggested by binary1248:

Code: [Select]
Name: CMAKE_MODULE_PATH
Type: PATH
Value: {SFML root directory}\cmake\Modules (The directory where FindSFML.cmake is.)
Title: SFGUI
Post by: Naufr4g0 on November 02, 2011, 12:31:44 pm
Tank, have you any user-guide in beta version? :D
Title: SFGUI
Post by: victorlevasseur on November 02, 2011, 06:36:54 pm
Tank, I saw a "c++11" branch in SFGUI :
Are you going to apply C++11 soon ? It's a problem because a lot of users doesn't use C++11 now, and in my case, I don't now if I can use C++11 with GCC 4.5.2 (MinGW) (this compilator is required by Game Develop, so...)
Title: SFGUI
Post by: Tank on November 02, 2011, 06:53:21 pm
@Naufr4g0:
No, it doesn't make sense yet. I'm glad I didn't write articles yet, because the API changed massively in the past days. ;) I'll announce it here when the guide is being written.

@victorlevasseur:
That depends on if it will lead to problems. However when having a "newer" compiler you shouldn't run into problems at all. GCC 4.5.2 does already support a lot of C++11's features, but I already found some which are not supported (e.g. range-based for or the "nullptr" constant).
The c++11 branch of SFGUI uses some of those, but I can drop them again. So GCC 4.5.2 will be absolutely no problem.

Regarding using it: In GCC you simply add the "--std=c++0x" flag. It's done automagically in the SFGUI CMake file but needs to be set in your projects, too.

Keep in mind that this hasn't been decided yet.
Title: SFGUI
Post by: asdatapel on November 02, 2011, 09:28:48 pm
hey tank. I managed to compile sfml, buut i cant use it. I looked at the test source but its really confusing, so it would be great if you could right one or two guides or tutorials. thanks
Title: SFGUI
Post by: MorleyDev on November 02, 2011, 10:06:28 pm
nullptr is in the latest versions of GCC starting with GCC 4.6, http://gcc.gnu.org/gcc-4.6/cxx0x_status.html

You can grab the build for windows at http://nuwen.net/ if possible ^^
Title: SFGUI
Post by: Tank on November 02, 2011, 11:13:23 pm
@asdapel
Writing a tutorial at the moment is useless. We will provide articles on how to use SFGUI when the "core" API is considered stable. Check the sample in samples/Test.cpp, should be pretty straight-forward for a beginning.

@MorleyDev
I'm aware of it and am using 4.6, but there are still many compatibility issues with wide-spread compiler versions, especially on different platforms. So it's generally a good idea to stay as compatible as possible so that the majority can use the library without adjustments. Btw, I can't make a use of Win builds, incompatible binary format ;-)

However I'd like to thank you guys for the feedback so far. It's very helpful and shows up problems and glitches we haven't encountered yet. And of course it's nice to see this beast generating interest. Keep it coming! :-)
Title: SFGUI
Post by: asdatapel on November 03, 2011, 12:44:50 am
ive checked it, but its kinda confusing. a small tutorial of the very basics would be very helpful
Title: SFGUI
Post by: binary1248 on November 03, 2011, 01:33:42 am
Quote from: "asdatapel"
ive checked it, but its kinda confusing. a small tutorial of the very basics would be very helpful


Yeah I admit we didn't think of the straightforwardness of the sample app. It was meant more for testing and showcasing purposes (hence it being samples/Test.cpp). Maybe if I find time tomorrow I'll write a small and concise example of the basic usage of the library with a bit more comments in the code. :wink:

For more advanced usage of the library we still expect users to refer to the doxygen API documentation that you can generate yourself if you have doxygen installed on your system. Soon we'll provide it online too at http://sfgui.sfml-dev.de/ so stay tuned.
Title: SFGUI
Post by: Naufr4g0 on November 03, 2011, 01:57:26 am
Quote from: "binary1248"

Yeah I admit we didn't think of the straightforwardness of the sample app. It was meant more for testing and showcasing purposes (hence it being samples/Test.cpp). Maybe if I find time tomorrow I'll write a small and concise example of the basic usage of the library with a bit more comments in the code. :wink:

For more advanced usage of the library we still expect users to refer to the doxygen API documentation that you can generate yourself if you have doxygen installed on your system. Soon we'll provide it online too at http://sfgui.sfml-dev.de/ so stay tuned.


I realized how to do a simple gui, but a small guide will be very useful, expecially on button styles.
Anyway this is a cropped image of my first sfgui project. :)

(http://dl.dropbox.com/u/4564869/Screenshots/sfgui_prog.png)
Title: SFGUI
Post by: Tank on November 03, 2011, 11:35:57 am
Nice it's working for you. What do you mean by "button styles"?
Title: SFGUI
Post by: asdatapel on November 03, 2011, 06:52:01 pm
oh yeah and i forgot to mention the test app exe provided doesnt work on my comp. It'll hang for a few minutes, and then randomly pop out button and stuff. its wierd.
Title: SFGUI
Post by: binary1248 on November 03, 2011, 08:38:31 pm
Quote from: "asdatapel"
oh yeah and i forgot to mention the test app exe provided doesnt work on my comp. It'll hang for a few minutes, and then randomly pop out button and stuff. its wierd.


Normally I wouldn't recommend just executing the exe on your computer without knowing against what versions of SFML and SFGUI it was linked against (assuming it was linked dynamically) if you aren't compiling it yourself that is. If it was linked statically and still exhibits such behavior, it would help if you could be more specific about what doesn't work or how it works if at all. Further you can try to comment out sections of the test app source and keep compiling and testing to isolate the offending code block / widget.

Better sample apps are coming soon though so hang in there.
Title: SFGUI
Post by: Tank on November 04, 2011, 12:21:35 am
I recommend to comment out the scrolled window widget in the test app. It uses render-to-image which is known to raise problems on some systems/setups. (another guy who tested SFGUI got a black screen)
Title: SFGUI
Post by: victorlevasseur on November 04, 2011, 07:10:50 am
Quote
You can grab the build for windows at http://nuwen.net/ if possible ^^

This version of GCC is needed by the SDK I use (to make a plug-in).
Title: SFGUI
Post by: Tank on November 04, 2011, 01:20:24 pm
Quote
Anyone know if GCC 4.5.2 support std::shared_ptr ?

Yup, it does.
Title: SFGUI
Post by: victorlevasseur on November 04, 2011, 01:22:53 pm
Ok, I have compile SFGUI beta branch with GCC 4.5.2, it works without Boost's warnings.  :D
Title: SFGUI
Post by: Tank on November 04, 2011, 01:51:53 pm
...because there's no Boost used anymore. ;) Great that it works for you.
Title: SFGUI
Post by: Tank on November 04, 2011, 05:43:58 pm
UPDATE

We recently merged our dev branch into master that fixed a lot of stuff and changed many things internally. Changes:



Have fun and tell us what you think. :-) Remember to visit the SFGUI forum (http://sfgui.sfml-dev.de/forum/) for reporting issues and/or getting support. This thread is primary for news.
Title: SFGUI
Post by: binary1248 on November 04, 2011, 06:24:20 pm
The current examples don't cover all widgets. More examples are bound to come soon covering the other widgets. Until then... I guess you can play around with the current ones :P
Title: SFGUI
Post by: victorlevasseur on November 04, 2011, 06:44:25 pm
Cool update. :)
But now, how can we receive the oldstate in the signal stateChanged, or the mouse position in the mouseClick signal ?
Title: SFGUI
Post by: asdatapel on November 04, 2011, 07:12:07 pm
so ive been looking at the examples. It looks like everything requires a window. Is it possible to do without?
Title: SFGUI
Post by: binary1248 on November 04, 2011, 08:03:58 pm
Quote from: "victorlevasseur"
Cool update. :)
But now, how can we receive the oldstate in the signal stateChanged, or the mouse position in the mouseClick signal ?


Well when you receive an OnClick signal you can query SFML for the mouse coordinates yourself. Or am I misunderstanding something? Using SFGUI doesn't prohibit you from using SFML as usual. And regarding state change.. may I ask why you need the old state?

Quote from: "asdatapel"
so ive been looking at the examples. It looks like everything requires a window. Is it possible to do without?


Just replace your window by the widget you want to use and send it the events and and draw it every frame. You have to do that with every widget and you won't have to use a window.
Title: SFGUI
Post by: Naufr4g0 on November 04, 2011, 09:45:39 pm
Wow an update! :D
I can configure e generate build files, but I obtain some annoying warnings, that don't allow me to build the library (with a lot of errors)

Code: [Select]

WARNING: Target "Box" requests linking to directory "C:/sfml/sfml2".  Targets may link only to libraries.  CMake is dropping the item.
WARNING: Target "Button" requests linking to directory "C:/sfml/sfml2".  Targets may link only to libraries.  CMake is dropping the item.
WARNING: Target "Entry" requests linking to directory "C:/sfml/sfml2".  Targets may link only to libraries.  CMake is dropping the item.
...
Title: SFGUI
Post by: victorlevasseur on November 04, 2011, 10:01:24 pm
It was just an example, it's useless.

What do you mind by "remove hook" ? Is this linked to the fact that I had to manage manually widgets' focus (in the previous version of SFGUI donwloaded before this update) because I don't use container ?
Title: SFGUI
Post by: binary1248 on November 04, 2011, 10:39:19 pm
Quote from: "victorlevasseur"
It was just an example, it's useless.

What do you mind by "remove hook" ? Is this linked to the fact that I had to manage manually widgets' focus (in the previous version of SFGUI donwloaded before this update) because I don't use container ?


Hooking was a mechanism used internally to make sure some widgets got high priority access to certain events. It bypassed most of the hierarchical event passing and was therefore removed to clean up the library a bit.

In principle all widgets were designed to be used within some sort of container be it a window or box etc. Adding your widgets to your application one by one without use of a root container isn't recommended because as you mentioned focus changing won't get handled properly, among other things. Please try to use windows as much as you can or if you don't want a window then a box as the root widget.

Quote from: "Naufr4g0"
Wow an update! :D
I can configure e generate build files, but I obtain some annoying warnings, that don't allow me to build the library (with a lot of errors)

Code: [Select]

WARNING: Target "Box" requests linking to directory "C:/sfml/sfml2".  Targets may link only to libraries.  CMake is dropping the item.
WARNING: Target "Button" requests linking to directory "C:/sfml/sfml2".  Targets may link only to libraries.  CMake is dropping the item.
WARNING: Target "Entry" requests linking to directory "C:/sfml/sfml2".  Targets may link only to libraries.  CMake is dropping the item.
...


It seems like you set your SFML library file paths wrong. Instead of "C:/sfml/sfml2" you should set it to something like "C:/sfml/sfml2/lib/libsfml-window-s.a" for example (if you are using GCC). Note that it is a FILE PATH and not a DIRECTORY PATH. You have to give CMake the right path for each of the library files it needs. Hope this helps.
Title: SFGUI
Post by: Naufr4g0 on November 04, 2011, 11:14:29 pm
Quote from: "binary1248"

It seems like you set your SFML library file paths wrong. Instead of "C:/sfml/sfml2" you should set it to something like "C:/sfml/sfml2/lib/libsfml-window-s.a" for example (if you are using GCC). Note that it is a FILE PATH and not a DIRECTORY PATH. You have to give CMake the right path for each of the library files it needs. Hope this helps.


Ok with your suggestions I solved build files generation issue! :D
Anyway when I build the solution under VS2010 I get 8 MSB3073 errors in the file:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
:(

Update: the issue was only examples-related (maybe). Nevertheless I obtained lib files :)
Title: SFGUI
Post by: Naufr4g0 on November 05, 2011, 01:19:28 am
I have another events handler in my project, executed after sfgui-related handler.
How can I prevent the canvas.HandleEvents() method is called when a sfgui event occurs?
This is a piece of my code:

Code: [Select]

   while( window.IsOpened() ) {

while( window.PollEvent( event ) ) {
// sfgui events
m_wndmain->HandleEvent( event );
// sfml window events
if( event.Type == sf::Event::Closed ) window.Close();
// canvas events
canvas.HandleEvents(event);
}

window.Clear( sf::Color::Black );
window.Draw( text );
canvas.Draw(window);
m_wndmain->Expose( window );
window.Display();
}
Title: SFGUI
Post by: binary1248 on November 05, 2011, 02:18:46 am
Quote from: "Naufr4g0"

Ok with your suggestions I solved build files generation issue! :D
Anyway when I build the solution under VS2010 I get 8 MSB3073 errors in the file:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets
:(

Update: the issue was only examples-related (maybe). Nevertheless I obtained lib files :)


This should be fixed in a patch applied as soon as Tank comes around. Thanks for reporting it.

Quote from: "Naufr4g0"
I have another events handler in my project, executed after sfgui-related handler.
How can I prevent the canvas.HandleEvents() method is called when a sfgui event occurs?


If I understand you correctly, you want to prevent the event from being handled by your canvas if SFGUI made use of it, i.e. it resulted in something happening with the GUI. Because the recommended way of using SFGUI is by containing all widgets within a root widget (mostly a window or box) and sending that widget all SFML events, all you have to do is Connect() the signals you are interested in and set a flag to prevent sending the currently processed event on to your canvas when SFGUI signals that it did something.

Code: [Select]

   bool block_event = false;

   ...

   m_wndmain->OnMouseButtonPress.Connect( &SFGUIConsume );

   ... more Signal types here ...

   while( window.IsOpened() ) {

while( window.PollEvent( event ) ) {
// sfgui events
m_wndmain->HandleEvent( event );
// sfml window events
if( event.Type == sf::Event::Closed ) window.Close();
// canvas events
if( !block_event ) {
canvas.HandleEvents(event);
}
block_event = false;
}

window.Clear( sf::Color::Black );
window.Draw( text );
canvas.Draw(window);
m_wndmain->Expose( window );
window.Display();
   }

   ...

   void SFGUIConsume() {
    block_event = true;
   }


Hope I understood you correctly and was able to help.
Title: SFGUI
Post by: Naufr4g0 on November 05, 2011, 01:36:39 pm
Quote from: "binary1248"

Hope I understood you correctly and was able to help.


Now it works! Thanks for your valuable tips! :)
I think SFGUI have the necessary requirements to become a new standard for GUIs under SFML library. :)
Title: SFGUI
Post by: asdatapel on November 05, 2011, 07:20:45 pm
Ive run into a problem. I cant add anything into a window becuase it gives an error
Code: [Select]
undefined reference to `_imp___ZN3sfg9Container3AddEN5boost10shared_ptrINS_6WidgetEEE'|
Also, I tried to do a button by itself but there are problems with that to. When I create a button and run in debug mode, all i get is a black screen, even if all i do is Create() it.
Title: SFGUI
Post by: keyforge on November 05, 2011, 07:47:06 pm
I get an error unresolved external symbol public static class sf::Color const sf::Color::Black in Brew.obj
Title: SFGUI
Post by: victorlevasseur on November 05, 2011, 07:59:43 pm
Compile your project with C++0x :
Code: [Select]
--std=c++0x

But, Tank said :
Quote
Please use our forum for support!

http://sfgui.sfml-dev.de/forum/
Title: SFGUI
Post by: binary1248 on November 05, 2011, 08:05:47 pm
Quote from: "asdatapel"
Ive run into a problem. I cant add anything into a window becuase it gives an error
Code: [Select]
undefined reference to `_imp___ZN3sfg9Container3AddEN5boost10shared_ptrINS_6WidgetEEE'|
Also, I tried to do a button by itself but there are problems with that to. When I create a button and run in debug mode, all i get is a black screen, even if all i do is Create() it.


Try compiling the latest master from Git.

Quote from: "keyforge"
I get an error unresolved external symbol public static class sf::Color const sf::Color::Black in Brew.obj


Try checking whether SFML_STATIC is selected in CMake or not. If you compiled SFML as a static library it must be checked. If not then it must not be checked.
Title: SFGUI
Post by: asdatapel on November 05, 2011, 08:08:27 pm
Alright I did that, but the black screens still there
Title: SFGUI
Post by: asdatapel on November 05, 2011, 09:20:52 pm
Now adding the button the window works, but the
Code: [Select]

Button->OnClick.Connect(&function)

gives me a
Code: [Select]

undefined reference to `sfg::Signal::Connect(sfg::Delegate)
Title: SFGUI
Post by: keyforge on November 05, 2011, 10:28:10 pm
Oh, ok! I was using SFML as a static lib but linked the dynamic libs.

I'm so stupid sometimes  :oops:

But when running the examples, they don't work. I get an 'an internal opengl call failed.' error for each of them.
Title: SFGUI
Post by: keyforge on November 05, 2011, 10:40:02 pm
Quote from: "asdatapel"
Now adding the button the window works, but the
Code: [Select]

Button->OnClick.Connect(&function)

gives me a
Code: [Select]

undefined reference to `sfg::Signal::Connect(sfg::Delegate)


Same here, got the exact same error.
Title: SFGUI
Post by: binary1248 on November 06, 2011, 12:44:18 am
Quote from: "asdatapel"
Now adding the button the window works, but the
Code: [Select]

Button->OnClick.Connect(&function)

gives me a
Code: [Select]

undefined reference to `sfg::Signal::Connect(sfg::Delegate)


Yeah this has been reported already and a patch has been submitted for Tank to ratify and pull into master. If you can't wait:

You have to add:

Code: [Select]

...
#include <SFGUI/Config.hpp>
...
class SFGUI_API Signal {
...


... to include/SFGUI/Signal.hpp

Quote from: "keyforge"
Oh, ok! I was using SFML as a static lib but linked the dynamic libs.

I'm so stupid sometimes  :oops:

But when running the examples, they don't work. I get an 'an internal opengl call failed.' error for each of them.


Wow, that is the first time I've seen an OpenGL error being generated when running SFGUI. Unfortunately I can't help any further there. What you could do however is run the examples in debug mode and step through each line of the code. As soon as you see that message on the console make note of the line/function that is currently being executed and report back here. I'll be able to help then.
Title: SFGUI
Post by: asdatapel on November 06, 2011, 01:11:29 am
So what about the black screen with a button in debug mode?
Title: SFGUI
Post by: binary1248 on November 06, 2011, 02:13:27 am
Quote from: "asdatapel"
So what about the black screen with a button in debug mode?


Could you describe your problem a bit more? You said all you did was Create() a button. How did you render it? Did you try to render it directly to the screen?

You can try to add it to a window after getting a fresh copy of master and making the changes I described in the last post. Remember to always run CMake again and do a complete rebuild of the library every time you get a new version. Try to render the window then and see if that will work. Maybe you could provide a working (as in compilable) minimal code example where you get a black screen. From your description it doesn't seem to be too complex.
Title: SFGUI
Post by: Tank on November 06, 2011, 02:32:40 am
Patches for MSVC problems have been applied to master, thanks to Sven for them.

Guys, please visit http://sfgui.sfml-dev.de/forum/ for SFGUI support/Q&A. It's better to not annoy SFML's userbase with SFGUI-related issues/support/whatever. .)
Title: SFGUI
Post by: asdatapel on November 06, 2011, 06:50:57 pm
Quote from: "binary1248"

Could you describe your problem a bit more? You said all you did was Create() a button. How did you render it? Did you try to render it directly to the screen?

First I tried everything with a window, but i got the black screen so started commenting out lines of code. Even when I have nothing besides the Create() function the screen stays black. I dont even try to render.
Title: SFGUI
Post by: binary1248 on November 06, 2011, 07:44:06 pm
Quote from: "asdatapel"

First I tried everything with a window, but i got the black screen so started commenting out lines of code. Even when I have nothing besides the Create() function the screen stays black. I dont even try to render.


If you don't render anything, it is expected that the screen stays black. When you call sf::Window::Clear() it clears the screen to the background color (Black by default). Merely Create()ing a button or any widget for that matter will not result in you seeing it on screen. You have to render it to the screen to see it.

SFML renders everything in immediate mode meaning that if you don't explicitly render an object you have created every frame you won't see it. Because SFGUI builds on SFML it too renders everything in immediate mode meaning that you have to call Expose() yourself every frame to render any widget to the screen.

You may think that SFGUI retains a list of Widgets that you created and renders them automatically every frame, but this is not the case.

If you don't render anything yourself, you also won't see anything.
Title: SFGUI
Post by: asdatapel on November 06, 2011, 08:20:37 pm
Quote from: "binary1248"
Quote from: "asdatapel"

First I tried everything with a window, but i got the black screen so started commenting out lines of code. Even when I have nothing besides the Create() function the screen stays black. I dont even try to render.


If you don't render anything, it is expected that the screen stays black. When you call sf::Window::Clear() it clears the screen to the background color (Black by default). Merely Create()ing a button or any widget for that matter will not result in you seeing it on screen. You have to render it to the screen to see it.

SFML renders everything in immediate mode meaning that if you don't explicitly render an object you have created every frame you won't see it. Because SFGUI builds on SFML it too renders everything in immediate mode meaning that you have to call Expose() yourself every frame to render any widget to the screen.

You may think that SFGUI retains a list of Widgets that you created and renders them automatically every frame, but this is not the case.

If you don't render anything yourself, you also won't see anything.

LOL no I tried rendering it with exposed and even changed the windoe.Clear() color, but id jusst stays black. It works properly in Release however
Title: SFGUI
Post by: OniLinkPlus on November 06, 2011, 10:04:27 pm
Boost has been removed finally? Yay, I'm hopping on board with this project!
Title: SFGUI
Post by: asdatapel on November 06, 2011, 10:15:54 pm
Also, is there a checkbox or a dropdown box widget?
Title: SFGUI
Post by: binary1248 on November 06, 2011, 10:23:01 pm
Quote from: "asdatapel"

LOL no I tried rendering it with exposed and even changed the windoe.Clear() color, but id jusst stays black. It works properly in Release however


Can you post a minimal code sample that exhibits this behavior? It would help us greatly in fixing the bug you described (if it is a bug).

Quote from: "asdatapel"
Also, is there a checkbox or a dropdown box widget?


Coming soon.
Title: SFGUI
Post by: OniLinkPlus on November 07, 2011, 01:14:20 am
I would enjoy seeing a notebook widget and a dropdown choice widget.
Title: SFGUI
Post by: binary1248 on November 07, 2011, 01:23:30 am
Quote from: "OniLink10"
I would enjoy seeing a notebook widget and a dropdown choice widget.


This was also planned a while ago.

To see what we have planned for the future you can visit: https://github.com/TankOs/SFGUI/wiki/TODO-List

Be sure to check out the SFGUI forum too.  We'd like to see how you use the library and might just get inspired to add a widget which would fit your requirements better.
Title: SFGUI
Post by: asdatapel on November 07, 2011, 05:51:39 am
alright i just compiled the new version and it works properly now. Thanks alot though
Title: SFGUI
Post by: Tank on November 07, 2011, 01:15:35 pm
UPDATE

Today I implemented sfg::Desktop, a managing class for rendering engines and widgets (preferable windows). Desktop manages stackable widgets with focus-switching and correct ordering.

If you want to check it out, get the commits from the desktop branch and run the "Desktop" example.

Here's a screenshot of the new feature:

(http://dl.dropbox.com/u/10016269/sfgui/sfgui_desktop.png)
Title: SFGUI
Post by: asdatapel on November 07, 2011, 08:19:37 pm
niiiiiice Question: How do you make a theme? Do you like make an iomage for each wigdet. Also how do u switch themes? Oh yeah, and are you using windows in that screenshot? If so, what theme is that?
Title: SFGUI
Post by: victorlevasseur on November 08, 2011, 07:24:00 am
The theme you see on the previous screen is made with only sf::Shape. (with BREW render engine, a sf::Shape based render engine for SFGUI)
So, you can customize the theme using the method :
Code: [Select]
sfg::Context::Get().GetEngine().SetProperty<TYPEOFPROPERTY>("selector", "property", VALUE);
Title: SFGUI
Post by: thePyro_13 on November 08, 2011, 08:28:40 am
This is looking so good. That latest screenshot is very Steamy(reminds me of the pre-2010 steam). :D
Title: SFGUI
Post by: Tank on November 08, 2011, 10:12:06 am
@asdatapel:
A theme can be made/applied in two ways: Either you set the properties manually in code (like victorlevasseur mentioned) or you load a theme from file, where binary's theme loader will kick in (it's not yet applied to master, so you won't see it right now).

Yes, I am using windows in the screenshot. It's the default theme of BREW (Basic Rendering Engine for Widgets), which utilizes shapes only.

For clarification:
SFGUI does not force you to use any fixed rendering for the widgets. Instead it oursources that functionality into so called "rendering engines". They simply get the widget's pointer and construct sf::Drawables.

SFGUI's reference implementation of a rendering engine is BREW, which -- like said before -- uses shapes. You can change colors, line widths etc., but the overall style won't change.

Themes are only properties that get loaded into the engine, so you're again able to modify colors, line widths etc., but not the overall style. This also means that images are not possible with BREW.

However another guy is currently developing the rendering engine "Bob" (http://en.wikipedia.org/wiki/Blitter_object) that uses textures (and therefore images) for rendering widgets.

If you've used Gnome before, it's just like that. You have all those rendering engines (Murrine, Aurora etc. pp.) that give a rather fixed overall look, but you can still change some properties here and there (colors, rounded edges etc.). If you like Windows, it's comparible to the oldschool design and the new shiny one.

@victorlevasseur:
You can leave out the template parameter, like:
Code: [Select]
sfg.:Context.:Get().GetEngine().SetProperty( "sel", "prop", 12345 );

With sfg::Desktop it's even easier:
Code: [Select]
desktop.SetProperty( "sel", "prop", 12345 );

@thePyro_13:
Correct, I took the colors from a Stream screenshot I found on Google. ;)
Title: SFGUI
Post by: Tank on November 08, 2011, 02:42:05 pm
UPDATE

And this, my friends, is why using layouters is so much fun: ;)
http://www.youtube.com/watch?v=lRVjubYPgLk

Features added:


All changes have already been applied to master. If you like check them out and tell us about your feelings. :)
Title: SFGUI
Post by: keyforge on November 08, 2011, 04:16:54 pm
Quote from: "thePyro_13"
This is looking so good. That latest screenshot is very Steamy(reminds me of the pre-2010 steam). :D


I agree, it looks good! (Also, the TF2 Pyro is amazing!)

I got SFML GUI working on GCC and Visual Studio 2010. I fried my laptop so I recompiled SFML on my desktop and it fixed the OpenGL errors. I'll definately be using it in my current project.
Title: SFGUI
Post by: asdatapel on November 08, 2011, 07:46:36 pm
Quote from: "Tank"

Yes, I am using windows in the screenshot. It's the default theme of BREW (Basic Rendering Engine for Widgets), which utilizes shapes only.
;)

no I meant the Windows window theme
Title: SFGUI
Post by: binary1248 on November 08, 2011, 08:07:31 pm
Quote from: "asdatapel"
Quote from: "Tank"

Yes, I am using windows in the screenshot. It's the default theme of BREW (Basic Rendering Engine for Widgets), which utilizes shapes only.
;)

no I meant the Windows window theme


lol no.. he is using Linux in the screenshot.
Title: SFGUI
Post by: asdatapel on November 08, 2011, 11:36:40 pm
Quote from: "binary1248"
Quote from: "asdatapel"
Quote from: "Tank"

Yes, I am using windows in the screenshot. It's the default theme of BREW (Basic Rendering Engine for Widgets), which utilizes shapes only.
;)

no I meant the Windows window theme


lol no.. he is using Linux in the screenshot.

but he just said hes using windows in the screenshot...
Title: SFGUI
Post by: binary1248 on November 09, 2011, 12:37:30 am
Quote from: "asdatapel"

but he just said hes using windows in the screenshot...


He meant he was using normal SFGUI windows and not the operating system Windows. Trust me there must be a really really special reason for him to even boot into Windows (OS) to do anything.
Title: SFGUI
Post by: Tank on November 09, 2011, 11:19:34 am
Quote from: "binary1248"
Trust me there must be a really really special reason for him to even boot into Windows (OS) to do anything.

lol

Didn't know you meant the window manager's window decoration, asdatapel. To clarify: The outside window is the one from my "operating system" (actually it's the window manager). All the other windows are sfg::Window. Not to mix up with MS Windows. :)
Title: SFGUI
Post by: asdatapel on November 09, 2011, 02:40:54 pm
lol I thought you were using a theme on Windows, and the theme looked goog, so I asked what it was
Title: SFGUI
Post by: Tank on November 10, 2011, 10:06:04 am
UPDATE
Title: SFGUI
Post by: Laurent on November 10, 2011, 10:44:16 am
Quote
binary1248 nearly completed the CSS parser with the help of the Embedded LL library. It's a header-only library that gets shipped with SFGUI

I was wondering what limitations a LGPL header-only library imposes. I found an answer in the FAQ of the Eigen library: basically, in this particular case, the "complicated" conditions of the LGPL don't apply and it's equivalent to the BSD license. They said it was confirmed by the FSF, so the information can be considered reliable.
Just in case someone else would wonder ;)
Title: SFGUI
Post by: binary1248 on November 10, 2011, 11:19:09 am
Quote from: "Laurent"
Quote
binary1248 nearly completed the CSS parser with the help of the Embedded LL library. It's a header-only library that gets shipped with SFGUI

I was wondering what limitations a LGPL header-only library imposes. I found an answer in the FAQ of the Eigen library: basically, in this particular case, the "complicated" conditions of the LGPL don't apply and it's equivalent to the BSD license. They said it was confirmed by the FSF, so the information can be considered reliable.
Just in case someone else would wonder ;)


Would be kind of lame if after all the effort I realize that SFGUI can't make use of ell don't you think? I did my research early enough :P Nice of you to take care of the (possibly) worrying users though ^^.
Title: SFGUI
Post by: Tank on November 10, 2011, 11:27:55 am
And another small update that shows how to use OpenGL with SFGUI (or SFML in general), as one user requested it on the SFGUI forum. I like the little application so I've created a tiny video for you. ;)

http://www.youtube.com/watch?v=AFdTPh8RtOc
Title: SFGUI
Post by: Groogy on November 10, 2011, 03:54:07 pm
I'm just curious how well the library will work in a multi threaded environment? Does it provide any tools for that or will I have to write it myself?

I'm just looking for GUI components for my editor and in-game and the worrying part is that all my graphics is rendered in it's own thread (so the GUI would have to be placed there) and I'm more or less worried if the GUI will have any problem with that and if the GUI do provide anything specifically targeted for such environments?
Title: SFGUI
Post by: deadalnix on November 10, 2011, 04:11:13 pm
You'll find classes Thread, Mutex and Lock in the module system.
Title: SFGUI
Post by: Tank on November 10, 2011, 04:26:34 pm
The library is definitely not thread-safe, but since you have to stick to one active thread for rendering anyways, it's mostly ot a problem at all.

Btw., multi-threading issues arise when you're really accessing/modifying stuff from more than one active thread. If you do all rendering in one thread whilst others are doing completely different things, you won't run into multi-threading issues with SFGUI.
Title: SFGUI
Post by: Groogy on November 10, 2011, 04:41:42 pm
Great sure, but how would I handle input? Is that separated somehow from the GUI components? So I can more or less do this:

Code: [Select]

void ButtonPressInLogicsCallback()
{
        Application::Instance().GetRenderer().EnableComponent( mySuperAwesomeGUIComponentID ); // Pass message to render thread
}


More easily explained, is it possible to have a MVC approach with your GUI library?
Title: SFGUI
Post by: Tank on November 10, 2011, 05:04:11 pm
Without checking in detail, it should be possible – at least to a high degree. ;) SFGUI stalls rendering stuff until Expose() is called, which renders everything to the rendering target. So even if you forcefully invalidate a widget (either by calling Invalidate() directly or by setting a property that would lead to an invalidation, like changing a label's text), the actual rendering is stalled until you're in your rendering loop/thread.

If your example above sends a message to a message pool that's being processed in a separate thread (that's also in control of it), then I don't see a problem at all.
Title: SFGUI
Post by: Groogy on November 10, 2011, 05:14:09 pm
Alright I'll have to do some trial and error to see if it works :) I'll let you know. It might take some time as I'll have to refactor my code to separate out things to be shared between editor and game in it's own library

Also don't you depend on Boost or something like that? At least I thought I read that somewhere but on your github page your only dependency are SFML2.
Title: SFGUI
Post by: Tank on November 10, 2011, 05:43:48 pm
We've dropped Boost 1-2 weeks before completely, so it's not needed anymore. What you need is a compiler that supports at least "some" C++11 (everything from GCC 4.3 and MSVC 2008 SP1/2 should be fine).
Title: SFGUI
Post by: Naufr4g0 on November 10, 2011, 06:08:57 pm
I updgraded sfgui libraries and I linked them to my project, but the size of my button changed. Why?

(http://dl.dropbox.com/u/4564869/Screenshots/sfgui_tall_button.png)

How can I resize buttons manually?
They are inside a sfg::box.
Title: SFGUI
Post by: Tank on November 10, 2011, 06:18:45 pm
Can you show the relevant code please?
Title: SFGUI
Post by: Naufr4g0 on November 10, 2011, 06:25:41 pm
Here's the code:

Code: [Select]

    // CREATE MAIN WIDGET
sfg::Window::Ptr m_wndmain = sfg::Window::Create();
m_wndmain->SetTitle( L"MENUBAR" );
m_wndmain->SetBorderWidth( 10.f );
m_wndmain->SetStyle( sfg::Window::Style::NoStyle );

// create box main widget
sfg::Box::Ptr m_mainbox = sfg::Box::Create ( sfg::Box::Orientation::Horizontal, 10.f);

// create buttons main widget
sfg::Button::Ptr m_button_select   ( sfg::Button::Create( L"Select"        ) );
sfg::Button::Ptr m_button_draw     ( sfg::Button::Create( L"Draw"          ) );
sfg::Button::Ptr m_button_dijkstra ( sfg::Button::Create( L"Shortest Path" ) );
sfg::Button::Ptr m_button_clarke   ( sfg::Button::Create( L"Clarke&Wright" ) );
sfg::Button::Ptr m_button_load     ( sfg::Button::Create( L"Load project"  ) );
sfg::Button::Ptr m_button_save     ( sfg::Button::Create( L"Save project"  ) );

// append buttons to box
m_mainbox->Pack ( m_button_select );
m_mainbox->Pack ( m_button_draw );
m_mainbox->Pack ( m_button_dijkstra );
m_mainbox->Pack ( m_button_clarke );
m_mainbox->Pack ( m_button_load );
m_mainbox->Pack ( m_button_save );

// append box to widget
m_wndmain->Add(m_mainbox);
Title: SFGUI
Post by: Tank on November 10, 2011, 06:31:55 pm
I'm able to reproduce it and already know where the problem is. Fix will come in some minutes. ;)
Title: SFGUI
Post by: Tank on November 10, 2011, 06:38:10 pm
Should work now, get the latest commit.
Title: SFGUI
Post by: Naufr4g0 on November 10, 2011, 07:03:36 pm
Quote from: "Tank"
Should work now, get the latest commit.


That's a very good news! :D
Title: SFGUI
Post by: Groogy on November 10, 2011, 07:30:10 pm
Sitting on the bus here and saw a problem with threads. This would most certainly happen at the same time:

Code: [Select]
... // logic code
widget.SetPosition(...);
... // moar code

Code: [Select]
... // render code
widget.Expose();
... // moar render code


What I need is to detach the logics, have it export a state object that is transfered to the graphics. Do you think it would take a lot of effort forking SFGUI and implement that?

I can't do everything trough messages as I first thought because the widget will have to send data back.And the architecture I have won't allow that and for good reasons.
Title: SFGUI
Post by: Tank on November 10, 2011, 07:47:23 pm
I'm not sure if I got you right. What do you mean by "happen at the same time"?

Can you make a little sequence diagram or something to illustrate the process? (hasn't to be graphical, ASCII/text is fine ;))
Title: SFGUI
Post by: Groogy on November 10, 2011, 08:19:45 pm
Don't know how I would illustrate it... hmmm

Code: [Select]

Logic                                                  renderer
   |                                                       |
   |                                                       |
 Renderer.CreateWidget( widget );  ->  queue               |
   |                                                    process messages
   |                                                              receive ptr to widget
 sometime in the future                                    |
   |                                                       |
   |                                                       |
 widget.SetPosition();                                widget.Expose();
   |                                                       |
   |                                                       |
 restart loop                                         restart loop

Well the SetPosition can be anything really, even several modifications. What I'm trying to say that I can be messing with data the widget is trying to read while it's rendering and eventually mess things up. Let's say I SetPosition to 400,300 and the logics thread manages to write the x position then it's position would be 400,0 and then expose is called and renders to that position. That's a mild error and not so serious. It becomes worse if I delete the widget and then send a message to remove it from the graphics side. Then it would be trying to render an object that does not exist anymore.

And why I can't use messages are because I would need to send back information that a widget has been clicked on, hovered above and stuff like that. I make the renderer the logic threads bitch which simplifies and optimizes the synchronization a lot. And well anyone familiar with Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_law) should know why that is necessary.

What I am thinking that I'll modify is that I detach input, logics and data from a widget into a separate class which can export a state class the original widget class can read and then render accordingly.

Code: [Select]

class WidgetState
{
public:
    GDE::AnyType GetParameter( const std::string &aName );

private:
    std::map< std::string, GDE::AnyType > myParameters;
};

class WidgetLogics
{
public:
    virtual const WidgetState *GetState() const;
};

class Widget
{
public:
    virtual WidgetLogics *DeattachLogics();

    virtual void ReadState( const WidgetState *aState );
};


Just a basics of what I'm thinking. The widget itself will still contain the logics so it can function entirely like originally intended but you can also deattach the logics from it and handle it separately and then you transfer the changes with the WidgetState class. When the Deattach function is called then the Widget looses all reference to the logics and will not do anything anymore no matter what. It can only be modified by the state interface after that.

I'm not requesting that you do it! I'm just thinking that I'll fork your project and modify it so that it becomes... well more of a MVC like architecture to the functionality that is already there.

Maybe you got some pointers?
Title: SFGUI
Post by: Tank on November 10, 2011, 08:32:20 pm
Quote
I'm not requesting that you do it! I'm just thinking that I'll fork your project and modify it so that it becomes... well more of a MVC like architecture to the functionality that is already there.

Yeah that's how I understood it, too. I just wanted to understand your problem. :)

Don't you think your design is a little bit too complicated? MVC is a popular design pattern, but IMHO it's not always a good idea to separate everything. My suggestion is to take the GUI as a big view unit in terms of MVC, and not separate further. (just suggestions, of course)

Logic in SFGUI is and should keep fixed and mostly internal, that's why a GUI can be mostly understood as being a pure view.

When it comes to multi-threading, you have to pay attention at several things, of course, but there should not be more than one instance managing it. If that's the case, you don't have to bother with sync issues at all.

If you really want to follow your approach, it will be a bunch of work. Can be done, e.g. by creating messages for every type of action the widgets can perform. But again I think it's just adding an unnecessary layer of abstraction with little to no benefit.
Title: SFGUI
Post by: Groogy on November 10, 2011, 08:40:56 pm
Quote from: "Tank"
Don't you think your design is a little bit too complicated?
It probably is but that's the best I could come up with that would let me easily separate input and logic from the rendering.
Correction: I meant work with it easily as two separate things.

Quote from: "Tank"
MVC is a popular design pattern, but IMHO it's not always a good idea to separate everything. My suggestion is to take the GUI as a big view unit in terms of MVC, and not separate further. (just suggestions, of course)
I agree and I'm not doing a MVC pattern over it, I said MVC like because it's the closest resemblance.

Quote from: "Tank"
Logic in SFGUI is and should keep fixed and mostly internal, that's why a GUI can be mostly understood as being a pure view.
The scenario I'm worried about is that I have the logics at the main thread, the rendering of the widget in a separate thread. An event is fired, the user has clicked on the widget and the widget starts handling it and the internal state of the widget or another widget is changed. Before the widget is done with handling this the widget is exposed in the rendering thread. Let's say for instance I have a button I press on and when pressed itself, or any other widget, changes text or any other attribute. That would be very very bad.

I hope that's clear enough what the underlying problem is :D
Title: SFGUI
Post by: Tank on November 10, 2011, 09:13:02 pm
Well if that's your only concern, it should be very easy to implement. Just dispatch a message in the signal handlers of the widgets and you're good to go. :)
Title: SFGUI
Post by: Groogy on November 10, 2011, 09:27:14 pm
Quote from: "Tank"
Just dispatch a message in the signal handlers of the widgets
back to the logic thread? Making my synchronization point more complex is not desirable. I would like to see that as a last resort. The application will only be as fast as it's slowest synchronization point. Serial code is evil :twisted:

I was also thinking that the GUI could be completely on the logic side, be rendered to a double buffered structure of render textures which are swapped at synchronization(which will be a lot faster than messages) and it would let the graphics thread focus more on game graphics. I can only see it as a problem if I become CPU bound but then I can come up with some nifty solutions to parallel the GUI as well along side the logic calculations. Though that would mean that all the game logics would have to wait and depend on the GUI? But it probably would have to do that anyway.

ah trade off's trade off's. Notice how I like to talk to reach solutions? ^^ Sorry if I've bothered you too much with none essentials.

Anyway the library looks great, easy to integrate and stable. Best thing is that I won't have to mess around in the GUI code or reinvent the wheel :D
Title: SFGUI
Post by: Tank on November 11, 2011, 08:13:01 am
The biggest problem seems to be that your application is rather complex in its design, so it's hard to follow what you actually want to do in detail. ;)

I don't think you need to move the GUI to a separate thread. The most time-consuming actions in SFGUI are:


Size requests and allocations only happen if the geometry changes, so this can mostly be ignored for performance issues. Exposing is a must-have, else you won't see anything. ;) However we haven't ran into performance issues yet. Event handling is also a must-have, except you only want visuals. :)

The only thing that could be moved to a separate thread are the position and size operations. Those are mostly triggered through events, therefore you COULD move HandleEvent() to a separate thread.

But I encourage you to try it out serially at first and see if performance is okay for you. The extra load of synchronization and stuff may not be worth.
Title: SFGUI
Post by: Groogy on November 11, 2011, 03:07:22 pm
Quote from: "Tank"
The biggest problem seems to be that your application is rather complex in its design, so it's hard to follow what you actually want to do in detail. ;)
It's not that complex, but it might appear complex if you are an outsider and the code is not even available, I have a state stack, a loading thread, a rendering thread and the synchronization point for rendering(loading uses mutexes instead, was easier and acceptable since it's not at runtime it's used).
Quote from: "Tank"
I don't think you need to move the GUI to a separate thread.
I don't think so either, if you remember I said
Quote from: "Groogy"
if I become CPU bound
I never try to do anything optimized without having real numbers from test benchmarks showing that it will really work.

Make it work, Make it right, Make it fast is a very good mantra.
Title: SFGUI
Post by: binary1248 on November 11, 2011, 04:28:42 pm
Quote from: "Groogy"

Make it work, Make it right, Make it fast is a very good mantra.


Which is how we implement new features in SFGUI too. :)

As Tank said, how it is now I'd say the computation time ratio between HandleEvent() and Expose() is probably <1/99 and both make up almost all the time the library needs. Separating event handling and rendering into 2 different threads won't help much unless you plan on passing many MANY events to the library. In that case I would seek the source of the problem elsewhere ;).

The only way you can make SFGUI less of a bottleneck is therefore by speeding up Expose(). Since I've been optimizing the performance of the library lately, I can tell you that SFGUI isn't even the culprit of the long time spent in Expose(). In fact 1 level down the calltree and you'll only find calls to SFML which is where Expose() lingers for almost all of it's time. Since SFML renders through OpenGL it also wouldn't make sense to try to optimize there. As explained nice and short here: http://www.opengl.org/wiki/OpenGL_and_multithreading if you only have 1 GPU all the calls to GL from multiple threads will end up in 1 queue anyway, thereby wasting any effort to render from different threads.

The #1 bottleneck is therefore SFML and it relies on GL calls which don't make sense to separate into multiple threads. If you want a performance increase with SFGUI I would rather talk to Laurent first than try to parallelise everything you can in SFGUI. If he can reduce the amount of GL calls per shape/text trust me, you won't have performance issues with SFGUI ever again ;).

As always I let numbers speak for themselves. Here is the top 10 list from the flat gprof profile of Test.cpp:
Code: [Select]

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total          
 time   seconds   seconds    calls  ms/call  ms/call  name
  9.08      0.82     0.82 16418394     0.00     0.00  sf::Renderer::ProcessVertex(float, float, float, float, float, float, float, float)
  9.08      1.64     0.82                             tt_cmap4_char_map_binary
  7.25      2.29     0.66   175952     0.00     0.03  sf::Text::Render(sf::RenderTarget&, sf::Renderer&) const
  6.31      2.87     0.57 16418394     0.00     0.00  sf::Matrix3::Transform(sf::Vector2<float> const&) const
  6.09      3.42     0.55                             tt_face_get_kerning
  4.87      3.85     0.44  3419834     0.00     0.00  sf::Texture::GetTexCoords(sf::Rect<int> const&) const
  4.32      4.25     0.39 32168534     0.00     0.00  std::less<unsigned int>::operator()(unsigned int const&, unsigned int const&) const
  3.88      4.59     0.35  3421964     0.00     0.00  std::_Rb_tree(std::_Rb_tree_node<std::pair<unsigned int const, sf::Glyph> >*, std::_Rb_tree_node<std::pair<unsigned int const, sf::Glyph> >*, unsigned int const&)
  3.88      4.95     0.35  3417478     0.00     0.00  sf::Renderer::AddVertex(float, float, sf::Color const&)
  2.77      5.20     0.25 32967353     0.00     0.00  sf::Vector2<float>::Vector2(float, float)


The first SFGUI call ( Expose() ) comes at position 25:
Code: [Select]

0.72      7.03     0.07   374017     0.00     0.02  sfg::Widget::Expose(sf::RenderTarget&)
Title: SFGUI
Post by: asdatapel on November 11, 2011, 04:34:33 pm
my app is using an sfgui window, and i want to be able to move it anywhere. Unfortunatly, this means that even when the gui is clicked, my program registers  it as a click, so both the gui is affected, and the thying underneath it. Is there a way to cancel out the Event is sfgui does something with it?
Title: SFGUI
Post by: binary1248 on November 11, 2011, 04:39:26 pm
Quote from: "asdatapel"
my app is using an sfgui window, and i want to be able to move it anywhere. Unfortunatly, this means that even when the gui is clicked, my program registers  it as a click, so both the gui is affected, and the thying underneath it. Is there a way to cancel out the Event is sfgui does something with it?


http://www.sfml-dev.org/forum/viewtopic.php?p=41132&highlight=#41132
Title: SFGUI
Post by: Groogy on November 13, 2011, 11:25:17 pm
Alright SFGUI compiled but one of the examples didn't work. At least for MinGW make files. It was unable to compile the desktop example and the output was:

Code: [Select]
Scanning dependencies of target Desktop
mingw32-make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x004132f6)
mingw32-make[1]: *** [examples/CMakeFiles/Desktop.dir/all] Error 255
mingw32-make: *** [all] Error 2
Title: SFGUI
Post by: binary1248 on November 14, 2011, 12:24:20 am
Quote from: "Groogy"
Alright SFGUI compiled but one of the examples didn't work. At least for MinGW make files. It was unable to compile the desktop example and the output was:

Code: [Select]
Scanning dependencies of target Desktop
mingw32-make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x004132f6)
mingw32-make[1]: *** [examples/CMakeFiles/Desktop.dir/all] Error 255
mingw32-make: *** [all] Error 2


It looks like it is a problem with your MinGW. The CMakeLists.txt shouldn't (not even in the worst case) cause MinGW to cause an access violation. Any errors in CMakeLists.txt is (hopefully) caught before the Makefile is created. I can compile it on my MinGW and CMake just fine.

CMake 2.8.3
mingw32-make (i386-pc-mingw32) 3.82
gcc 4.5.0
Title: SFGUI
Post by: Groogy on November 14, 2011, 12:51:29 am
I got the same except for GCC which is version 4.6.1 and the weird thing is that it only happens in the desktop example. I'll try and manually compile that example and see what happens.

Also do you guys have any kind of logo for SFGUI that I could use on my loading screen? Tried to find but couldn't see any one really available.
Title: SFGUI
Post by: binary1248 on November 14, 2011, 03:45:15 am
Tank's the one in charge of the design/creative side of the library so it's better if I let him answer himself. :wink:
Title: SFGUI
Post by: Groogy on November 14, 2011, 10:17:14 am
Ow yeah also, noticed there were no progress bar widget? :P
I could probably make it myself but it's kind of common to have so thought I could just let it slip in as a suggestion.
Title: SFGUI
Post by: Tank on November 14, 2011, 11:52:03 am
Unfortunately there's no logo yet, so if any creative guy would like to create one, send them in! ;)

Edit
@Groogy:
The progress bar is on the Todo list.
Title: SFGUI
Post by: Groogy on November 14, 2011, 12:32:42 pm
Maybe something like I have here for SFML2?

(https://legacy.sfmluploads.org/cache/pics/175_loading%20screen.png)

The logo proposed by Haikarainen but with a little modification to show that the screen is not frozen(the cogs rotate)

Or I could add something like text under SFML2 logo stating "SFGUI inside" or "with SFGUI" or whatever :P
Point is I just want to show credit to the various libraries I borrow.
Title: SFGUI
Post by: Tank on November 14, 2011, 02:28:23 pm
I did this one really quick: (http://sfgui.sfml-dev.de/static/images/banner.png)

Since I'm not a designer at all, I'd be happy if one could come up with a nice idea. ;)
Title: SFGUI
Post by: Tank on November 14, 2011, 02:35:42 pm
*** UPDATE ***



Changes haven't been applied to master yet, you can find them in the BETA branch (https://github.com/TankOs/SFGUI/tree/BETA). And this is what the current state looks like:

(http://www.abload.de/thumb/sfgui_pbnxuad.png) (http://www.abload.de/image.php?img=sfgui_pbnxuad.png)

...and after a theme change: (credits for the styles go to binary1248, he should have been a designer instead of a programmer, I guess! ;))

(http://www.abload.de/thumb/sfgui_pb_2qpule.png) (http://www.abload.de/image.php?img=sfgui_pb_2qpule.png)
Title: SFGUI
Post by: asdatapel on November 14, 2011, 07:52:20 pm
niiiiice, what about a radiobutton widget?
Title: SFGUI
Post by: binary1248 on November 14, 2011, 08:18:57 pm
Quote from: "asdatapel"
niiiiice, what about a radiobutton widget?


https://github.com/TankOs/SFGUI/wiki/TODO-List

Coming soon.
Title: SFGUI
Post by: Tank on November 15, 2011, 10:45:18 am
The changes mentioned above have been applied to master. Feel free to test the stuff out and please give feedback if anything doesn't work out for you.

Wildcard sub-selectors have also been implemented, e.g.:

Code: [Select]
Window > * > Label { ... }

Matches to all Label widgets somewhere underneath a Window widget. This will later be overseeded by

Code: [Select]
Window Label { ... }

(like used in CSS). The > selector will still be available; it will act as the direct descendant, so

Code: [Select]
Window > Label

will match Label widgets that are direct children of Window widgets.
Title: SFGUI
Post by: Tank on November 15, 2011, 04:25:47 pm
Working on sfg::ListBox now:

(http://www.abload.de/thumb/lbf0unj.png) (http://www.abload.de/img/lbf0unj.png)
Title: SFGUI
Post by: victorlevasseur on November 15, 2011, 07:22:28 pm
you are very fast  :D
Great work.  :D
Title: SFGUI
Post by: Tank on November 18, 2011, 04:53:15 am
*** UPDATE ***
Title: SFGUI
Post by: Tank on November 28, 2011, 03:07:36 pm
*** UPDATE ***



All changes are NOT yet in the master branch. Expect them to be merged tomorrow.
Title: SFGUI
Post by: asdatapel on November 28, 2011, 07:52:28 pm
yayyyyyy!
still waiting for radiobuttons and dropboxes though.....
Title: SFGUI
Post by: victorlevasseur on November 28, 2011, 08:25:44 pm
Good update  :)
I can't wait the combobox ! :lol:
Title: SFGUI
Post by: OniLinkPlus on November 29, 2011, 12:13:10 am
Hey guys, I'm the one working on the Combo Boxes/Dropdown boxes. It's almost done, there's just on small issue that needs to be worked out. If I can locate a solution, it should be ready to go by the end of the day (Pacific Time).
Title: SFGUI
Post by: OniLinkPlus on November 29, 2011, 04:39:30 am
The combo box has been committed. All that remains is for Tank to accept it.
Title: SFGUI
Post by: Tank on November 29, 2011, 08:31:29 am
Hey guys, thanks for your feedback.

We prefer to stabilize the library whenever needed before adding new features. This even affects bigger parts of internal code (and sometimes also the API) to make it more bug-free, faster and more consistent. That's the reason you're still waiting for some missing widgets. "Don't fear the refactoring" ;)

One thing is for sure: Implementing new widgets is easy, keeping the good level up is another story.

ListBox is still in the pipeline and got stalled due to more important things. OniLink10 is developing the ComboBox which is being reviewed and tested. You see, we're working hard for reaching 0.0-alpha. ;) And don't forget binary1248 – it turned out he's a hell of an optimizer guy profiling the library to its extents. To give you an idea: With his help we could raise FPS in the test application from ~500 to ~1400 (numbers from my system).

So there's much stuff going on, but please note that killing bugs and making the library more solid have always a higher priority on our lists than throwing in buggy and/or untested new stuff.

However thank you all for your feedback, and don't hesitate to test the library (even BETA branch) and report every single bug or glitch you can find.
Title: SFGUI
Post by: victorlevasseur on November 29, 2011, 07:18:22 pm
Yeap, I have tested the BETA branch, it works without bugs or glitch.
And the use of its own SharedPtr is very good : it avoids the C++11 dependency.  :D
Title: SFGUI
Post by: OniLinkPlus on November 30, 2011, 01:10:18 am
I've got a few more things I need to implement in the ComboBox before it will be completely ready for pulling into master. I need to come up with a good system for the behavior of selected items when new items are added or old items are destroyed (the techniques I've tried have each had their own unnatural implications), and I need to tweak the rendering to fit with what Tank has in mind.
Title: SFGUI Git does not build.
Post by: xethm55 on December 09, 2011, 06:07:53 pm
It appears that the current git is broken.  There are still references to std::shared_ptr<>, ResizeWindow no longer exists, AllocateSize calls, etc.
Title: SFGUI
Post by: Tank on December 09, 2011, 06:22:19 pm
Can't reproduce, checked everything with "grep". In case you've installed SFGUI to your system somewhere, make sure to re-install after changes have been made. Otherwise you might use mixed versions of SFGUI.

What's your commit ID?
Title: SFGUI
Post by: xethm55 on December 10, 2011, 05:19:37 pm
:oops:  I removed what I had on my HD and re-cloned the git repo and everything is fine.
Title: SFGUI
Post by: Tank on December 11, 2011, 11:31:05 am
Hehe. ;) Good that you were able to solve it.
Title: SFGUI
Post by: Tank on December 11, 2011, 04:57:38 pm
*** UPDATE ***

A big update is being applied to the master branch of SFGUI (not at the moment, we always wait at least one day before applying development branches into master):



The ComboBox widget will stay in the development branch for some time because we have to implement some kind of z-ordering so that the popup stays on top.

If you want to test the new features now, check the PREPARE branch at GitHub. Here're two screenshots of the messy test application:

(http://www.abload.de/thumb/page03r2vq.png) (http://www.abload.de/image.php?img=page03r2vq.png) (http://www.abload.de/thumb/page1ye2ca.png) (http://www.abload.de/image.php?img=page1ye2ca.png)
Title: SFGUI
Post by: Tank on December 12, 2011, 04:48:11 pm
Just to let you know: Changes have been applied to master, and:

ComboBox has found its way in! Binary1248 implemented z-ordering so there's no reason for ComboBox to stay out. ;) Again many thanks to OniLink for doing it.

We're getting closer to a first release, so please report any bugs you may encounter or tell us about problems you have with SFGUI (API, behaviour, etc).

The ToDo list at GitHub shows what's still missing for a first release.
Title: SFGUI
Post by: victorlevasseur on December 12, 2011, 07:51:11 pm
Great work  :D .
Title: SFGUI
Post by: Tank on December 14, 2011, 05:53:33 pm
Good news for all CMake haters or "I don't like to build libraries myself"-guys: We have setup a Jenkins CI instance and do provide nightly builds, now. Check out SFGUI's download page: http://sfgui.sfml-dev.de/download

Currently only Windows 32 Bit, Visual Studio 10 and Linux 64 Bit, GCC libraries are being built. If anyone wants to donate some CPU resources to SFGUI for a different architecture/operating system mentioned above, then please contact us so that others can benefit from it.
Title: SFGUI
Post by: model76 on December 14, 2011, 06:35:03 pm
Quote
If anyone wants to donate some CPU resources to SFGUI for a different architecture/operating system mentioned above, then please contact us so that others can benefit from it.
What would this entail?
If you just need me to run something for you, then no problem.

I have Windows 7 64 bit and I believe also linux 32 bit. There is no compiler on the Windows box at the moment, but I would gladly install Visual C++ 2008 or 2010, as well as MinGW. The linux box of course comes with GCC.

I don't have all that much in the way of compiling expertise, but I do have some, and I also know how to follow instructions. ;)

Also, thanks for changing the license to zlib/png !
Title: SFGUI
Post by: Tank on December 14, 2011, 06:38:23 pm
Well Jenkins CI provides a very small Java program that does the whole job for you. We would also configure it so that you don't have to do anything but running it.

It works like this: You connect to our Jenkins master and as soon as it has new jobs, it commands the Jenkins nodes to compile and send compiled files back.

Win64 is already covered, but Win32 and MinGW are missing. Would you mind joining us at IRC? (channel #sfgui, server irc.boxbox.org) Maybe tomorrow, as I don't have time anymore today. ;)
Title: SFGUI
Post by: Laurent on December 14, 2011, 06:59:59 pm
I don't know much about Jenkins CI (but I'm definitely going to have a look at it!), but can't you use virtual machines to support other OSes that you can't run natively?
Title: SFGUI
Post by: Laurent on December 14, 2011, 07:06:55 pm
... and since you don't provide the corresponding SFML 2 build, people still have to build something ;)

You should at least put a link to the right revision of SFML in SFGUI's repository (with a git submodule), so that users know what to compile.
Title: SFGUI
Post by: Tank on December 14, 2011, 07:16:44 pm
Quote from: "Laurent"
I don't know much about Jenkins CI (but I'm definitely going to have a look at it!), but can't you use virtual machines to support other OSes that you can't run natively?

Yep exactly. Basically a virtual machine doesn't differ from a "real" machine, except it's, well, virtualized. ;) Jenkins supports some protocols for connecting to machines natively (Windows login, SSH) and a Java client for those machines that shall connect to the master.

Quote
... and since you don't provide the corresponding SFML 2 build, people still have to build something

That's why we're also setting up SFML2 for Jenkins. ;) (see the GitHub issue why it's still failing ;))

Quote
You should at least put a link to the right revision of SFML in SFGUI's repository (with a git submodule), so that users know what to compile.

Good idea.
Title: SFGUI
Post by: Laurent on December 14, 2011, 07:36:01 pm
Quote
Yep exactly. Basically a virtual machine doesn't differ from a "real" machine, except it's, well, virtualized.

I know :D
My point was: why don't you handle all the target OSes with virtual machines, instead of requesting external contributions?

Quote
see the GitHub issue why it's still failing

Which issue?
EDIT: ok I got it.
Title: SFGUI
Post by: Tank on December 14, 2011, 07:53:31 pm
Quote
My point was: why don't you handle all the target OSes with virtual machines, instead of requesting external contributions?

Because it's easier. I don't want 3 virtual machines for 32 Bit Linux, 32 Bit Windows and 64 Bit Windows. If users are using that anyway I don't need to setup virtual machines that I won't need for anything else.
Title: SFGUI
Post by: Tank on December 15, 2011, 01:44:16 am
SFGUI for Windows 64 Bit (MinGW) added.

We do now also provide binaries for the latest SFML2: Linux 64, Windows 32 (MinGW + MSVC10), Windows 64 (MinGW).

Get the files here: http://sfgui.sfml-dev.de/download

Keep in mind that the SFML2 builds are not official and development snapshots!
Title: SFGUI
Post by: LB on December 15, 2011, 02:22:21 pm
Quote from: "Tank"
If anyone wants to donate some CPU resources to SFGUI for a different architecture/operating system...


I have a Linux 32-bits (GCC) and a Windows 32-bits (MinGW). Are these useful? How can I help?
Title: SFGUI
Post by: Tank on December 15, 2011, 04:31:05 pm
Check your inbox. Especially the Linux 32 bit builds are missing.
Title: SFGUI
Post by: xethm55 on December 16, 2011, 07:14:23 pm
What version of MinGW / GCC combo is used for these builds?
Title: SFGUI
Post by: asdatapel on December 16, 2011, 08:00:03 pm
if i dont have to go through all that cmake crap, i can help with mingw 32
Title: SFGUI
Post by: Tank on December 16, 2011, 09:54:40 pm
Quote from: "xethm55"
What version of MinGW / GCC combo is used for these builds?

I'm unsure for MinGW, but for the Linux builds GCC 4.6.2 is used. I guess the MinGW builds are done with 4.5. However you should be able to use a different version.

@asdatapel:
Thanks for offering your help, however MinGW32 is already covered, see http://boxbox.org:8080/ . I'm going to add proper links to the SFGUI download page soon.
Title: SFGUI
Post by: Tank on December 16, 2011, 10:09:56 pm
Download page (http://sfgui.sfml-dev.de/download) updated. Everyone should be happy now. ;)
Title: SFGUI
Post by: Cpl.Bator on December 18, 2011, 01:19:15 pm
Thank tank , do you explain how to make our own custom gadget ?
Title: SFGUI
Post by: Tank on December 18, 2011, 02:22:27 pm
That will be covered in the user manual when it's written. ;)

For now you have to learn from source code. You can start by looking at sfg::Label or sfg::Button.

Keep in mind that if you throw in own widgets, you can't use the rendering engine for rendering. Instead you have to hardcore the rendering code in InvalidateImpl().

May I ask what kind of widget you need? Maybe it's better to implement it directly in SFGUI.
Title: SFGUI
Post by: Cpl.Bator on December 18, 2011, 04:47:36 pm
Custom widget can be graph , tree node , video widget , etc...
i go to see the source for learn. ;)

thx.
Title: Debug Build Problems
Post by: xethm55 on January 04, 2012, 07:25:13 pm
I am using one of the nightly builds from a few weeks ago (I tested with an updated version and still have the same problem) and when I try to debug, I get an access violation.  However, when I run in release mode, it works fine.

I am running on Windows 7 32bit with VS2010.

The exact error I get is below:
Code: [Select]

First-chance exception at 0x0f8b980b in ButtonTestd.exe: 0xC0000005: Access violation reading location 0xbaadf011.
Unhandled exception at 0x0f8b980b in ButtonTestd.exe: 0xC0000005: Access violation reading location 0xbaadf011.
The program '[2776] ButtonTestd.exe: Native' has exited with code -1073741819 (0xc0000005).


My project is located here: http://dl.dropbox.com/u/8892717/ButtonTest.zip
It uses premake, you'll need to run:
Code: [Select]
premake4 vs2010

Do I have some linker directive wrong?  I was thinking it might be possibly the string encoding.

[Edit]
Digging further, my problem appears to be that a private member variable, m_delegates, of the public member OnClick in the button class is non Null after the create method call on line 42 in ButtonTest.cpp - only when debugging.  Creating a different signal and assigning it to the OnClick variable results in the test app working.
Title: SFGUI
Post by: Tank on January 04, 2012, 11:43:08 pm
Please post a complete minimal example (just one .cpp file) and the backtrace of your debugger when the problem happens. Also update your nightly build is applicable.
Title: SFGUI
Post by: Elgan on January 05, 2012, 12:20:04 am
Looks great, Had librocket working well, but going to drop it to try this,


How about a slider widget?


will try it when I have free time, looks great though.










also GUI wise, if anyone needs simple simple, this has got to be the best UI and UI system I have ever seen..

http://www.antisphere.com/Wiki/tools:anttweakbar

works so well. amazing...fast and I like that its C style on top of C++ actually....

love how you can move it about, scale and reacts so well. (I knw how others can also do this , but it just seems smoother.

shame it has no user input/text box + images .

but for in game tools would be great..
Title: SFGUI
Post by: xethm55 on January 05, 2012, 04:32:52 am
Here is ButtonTest.cpp (the only cpp file in the above archive)
Code: [Select]

#include <SFGUI/Window.hpp>
#include <SFGUI/Desktop.hpp>
#include <SFGUI/Box.hpp>
#include <SFGUI/Table.hpp>
#include <SFGUI/Label.hpp>
#include <SFGUI/Entry.hpp>
#include <SFGUI/Button.hpp>
#include <SFGUI/Context.hpp>
#include <SFGUI/Engine.hpp>
#include <SFML/Graphics.hpp>

#include <string>
#include <sstream>
#include <cstdlib>


sf::RenderWindow* screen;


void OnButtonClicked()
{
}


int main(int argc, char* argv[])
{

// Initialize the time
screen = new sf::RenderWindow();
screen->Create(sf::VideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP), "Button Test");

// Create two buttons, one Client and one Server
sfg::Button::Ptr cbutton( sfg::Button::Create( "Test" ) );
cbutton->OnClick.Connect( &OnButtonClicked );


// Create a vertical box layout width 5 pixels spacing and add the label
// and button to it.
sfg::Box::Ptr box( sfg::Box::Create( sfg::Box::VERTICAL, 5.f ) );
box->Pack( cbutton, false );

// Create a window and add the box layouter to it. Also set some properties.
sfg::Window::Ptr window( sfg::Window::Create() );
window->Add( box );
window->SetTitle( "Testing" );
window->SetStyle( 3 ); // Title and Background

window->SetPosition(
sf::Vector2f(
static_cast<float>( screen->GetWidth() / 2 ) - window->GetAllocation().Width / 2.f,
static_cast<float>( screen->GetHeight() / 2 ) - window->GetAllocation().Height / 2.f
)
);

// Create a desktop and add the window to it. We need to specify the desktop
// area we want to use. In this case we use SFML window's whole area and
// therefore give it our render window to use its size.
sfg::Desktop desktop( *screen );

desktop.Add( window );

// Main loop!
sf::Event event;

while( ButtonClicked == 0 )
{
// Event processing.
while( screen->PollEvent( event ) )
{
desktop.HandleEvent( event );

// If window is about to be closed, leave program.
if( event.Type == sf::Event::Closed )
{
screen->Close();
}
}

// Rendering.
screen->Clear();
desktop.Expose( *screen );
screen->Display();
}

screen->Clear();

return 0;
}


This is the output of the debugger:
Code: [Select]

'ButtonTestd.exe': Loaded 'C:\Users\Terohnon\Downloads\ButtonTest\bin\ButtonTestd.exe', Symbols loaded.
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Users\Terohnon\Downloads\ButtonTest\bin\sfml-graphics-2.dll', Binary was not built with debug information.
'ButtonTestd.exe': Loaded 'C:\Users\Terohnon\Downloads\ButtonTest\bin\sfml-window-2.dll', Binary was not built with debug information.
'ButtonTestd.exe': Loaded 'C:\Users\Terohnon\Downloads\ButtonTest\bin\sfml-system-2.dll', Binary was not built with debug information.
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msvcp100.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msvcr100.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\opengl32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\glu32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\ddraw.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\dciman32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\oleaut32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\dwmapi.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\winmm.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Users\Terohnon\Downloads\ButtonTest\bin\sfgui.dll', Binary was not built with debug information.
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msvcp100d.dll', Symbols loaded.
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\apphelp.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\AppPatch\AcLayers.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\shlwapi.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\userenv.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\profapi.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\winspool.drv', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\mpr.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\uxtheme.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\atiglpxx.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\atioglxx.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\version.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\atigktxx.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\aticfx32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\atiadlxy.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\wtsapi32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\psapi.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\wintrust.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\crypt32.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\msasn1.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Unloaded 'C:\Windows\SysWOW64\atigktxx.dll'
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\atigktxx.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\dinput.dll', Cannot find or open the PDB file
'ButtonTestd.exe': Loaded 'C:\Windows\SysWOW64\hid.dll', Cannot find or open the PDB file
First-chance exception at 0x61ea980b in ButtonTestd.exe: 0xC0000005: Access violation reading location 0xbaadf011.
Unhandled exception at 0x77a115ee in ButtonTestd.exe: 0xC0000005: Access violation reading location 0xbaadf011.
The program '[2420] ButtonTestd.exe: Native' has exited with code -1073741819 (0xc0000005).


Note:  This was done on a 64bit Windows 7 System, but the error is the same as the 32 bit system.
Title: SFGUI
Post by: Mario on January 05, 2012, 04:30:55 pm
Recompile all library files yourself (SFML + SFGUI). I think you're trying to mix up Visual Studio versions here.
Title: SFGUI
Post by: xethm55 on January 05, 2012, 04:46:57 pm
I am using VC++ 2010 Version 10.0.30319.1 RTMRel.

I was under the impression that all libs build with VS2010 would work with any version of VS2010.  Is that wrong?

What version was used to build the libs supplied in the nightly builds?

[Edit 1]
I built SFML and SFGUI myself and linked them against my ButtonTest application.  I still get the same problems in debug mode.

[Edit 2]
When I link against the sfgui debug libs (build with the Debug target in the SFGUI solution), the test program works just fine.
Title: SFGUI
Post by: xethm55 on January 05, 2012, 10:10:54 pm
Linking to the debug libs appears to be a misdirection as I still have problems in other parts of SFGUI - specifically the Entry::GetPositionFromMouseX causes a segfault on line 70, where the m_visible_string is checked (this internally fails at the _Compare() function since the _Ptr points to 0xFFFFFFFF).

All my searches for the problems I am having indicate that the variables are not initialized.
Title: SFGUI
Post by: binary1248 on January 05, 2012, 10:42:33 pm
Quote from: "xethm55"
Linking to the debug libs appears to be a misdirection as I still have problems in other parts of SFGUI - specifically the Entry::GetPositionFromMouseX causes a segfault on line 70, where the m_visible_string is checked (this internally fails at the _Compare() function since the _Ptr points to 0xFFFFFFFF).

All my searches for the problems I am having indicate that the variables are not initialized.


GetPositionFromMouseX can't be called before all the members of Entry (including m_visible_string) are properly initialized in Entry's constructor. We also do periodic checks with valgrind to eliminate such programming errors. If m_visible_string isn't constructed properly the only reason would be because SFML didn't do it properly when told by SFGUI. Posting a minimal example as you did before to reproduce this error would be helpful. To reduce the clutter you might want to resort to using http://pastebin.com/ for that.

You said you link to the debug libs. I take it you also build your app in debug mode? If so run the app in your debugger and cause it to crash. Then you can post the full callstack/backtrace here for us to analyze. It is the most helpful piece of information to solve errors such as these.
Title: SFGUI
Post by: xethm55 on January 05, 2012, 11:32:02 pm
I managed to fix all of my debugging problems.  I am able to link to the released dynamic libs from the nightly build as well - and still be able to debug.  The solution was to use the following define:
Code: [Select]

_HAS_ITERATOR_DEBUGGING=0
Title: SFGUI
Post by: Elgan on January 07, 2012, 09:02:05 pm
I get access violation errors for

Code: [Select]


sfg::Label::Ptr _label( sfg::Label::Create( "Hello world!" ) );


Trying the hello world, in a non empty app.


using
Windows 32 Bit, Visual Studio 10 (SFML2 included)

from
http://sfgui.sfml-dev.de/download

Any pointers...no idea where I would go from here?




I am trying to compile from Git, but having massive trouble with Cmake and SFMLDIR...I hate cmake :(,. I point it to a folder where I have  compiled SFML 2..maybe debug/release issue? don't know...it says cant find. if I compile sfml into the same dir as the source from which I build it (using cmake and vs2k8). same issues.......but only trying to compile to see if it fixes the above


I would use the SF forums...but I cant register...I just cant get the captcha right...(I am nearly blind, PS the sound ones are horrible always,)...I can use magnifier, but the captcha is soo faded.
Title: SFGUI
Post by: binary1248 on January 07, 2012, 09:17:42 pm
Try creating the Label without passing a string to Create() and setting the text with SetText() after that. This might be related to another quirk I discovered recently.

Quote from: "Elgan"
I get access violation errors for
I would use the SF forums...but I cant register...I just cant get the captcha right...(I am nearly blind, PS the sound ones are horrible always,)...I can use magnifier, but the captcha is soo faded.


This is the sad result of being visited by a massive amount of spammers. Sadly if we make the Captcha any easier they will start showing up en masse again. Maybe Tank can figure something out...
Title: SFGUI
Post by: Elgan on January 07, 2012, 10:06:35 pm
Okei thanx,

alright:

I made a whole new app, win, console and used the "Hello world" tutorial code.

http://sfgui.sfml-dev.de/guide/getting_started/hello_world


same ,
Code: [Select]


sfg::Label::Ptr _label( sfg::Label::Create( ) );



Quote

Unhandled exception at 0x74efb9bc in sftest.exe: Microsoft C++ exception: std::length_error at memory location 0x0043fce8..
Title: SFGUI
Post by: binary1248 on January 07, 2012, 10:16:28 pm
Can you run it in debug mode and post the callstack/backtrace when it crashes? It's easier to tell where the exception was thrown that way.

Edit: Just so I don't forget to check this out when I have time, you might want to add this to our issue tracker on GitHub.
Title: SFGUI
Post by: Elgan on January 07, 2012, 11:39:00 pm
yep, but I think I need sfgui in debug mode too for more info, but not got it compiled just yet, I do not like cmake,

always get "project files may be invalid"...I can not get sfml dir right :S> I'm getting rather frustrated, nearly thinking about doing my chem calculations :@

SFML latest snapshot in sfml

sfml build and cmpiled into sfml/make

where should sfml_dir go?
the libs and dirs from sfml/debug/lib/debug I moved.

whats this cmakeconfig.cmake? where , what, how is this made, found, discovered?
Title: SFGUI
Post by: binary1248 on January 08, 2012, 12:28:42 am
Quote from: "Elgan"

whats this cmakeconfig.cmake? where , what, how is this made, found, discovered?


Never heard of such a file before.
Title: SFGUI
Post by: Elgan on January 08, 2012, 03:26:56 am
Code: [Select]

CMake Error at CMakeLists.txt:9 (find_package):
  Could not find module FindSFML.cmake or a configuration file for package
  SFML.

  Adjust CMAKE_MODULE_PATH to find FindSFML.cmake or set SFML_DIR to the
  directory containing a CMake configuration file for SFML.  The file will
  have one of the following names:

    SFMLConfig.cmake
    sfml-config.cmake


Well according to the docs of:
find_package( SFML 2.0 REQUIRED GRAPHICS WINDOW SYSTEM )

I should have a SFML.cmake  
else it looks for SFMLConfig.cmake

you say where sfml is installed...what does "installed" actually mean...? There is no SFML global variable as long as I know?
there is compiled...

sorry for all the hassle. I get angry enough at cmake...
Title: SFGUI
Post by: binary1248 on January 08, 2012, 03:47:40 am
Check this post (http://www.sfml-dev.org/forum/viewtopic.php?t=6112&postdays=0&postorder=asc&start=35).
Title: SFGUI
Post by: xethm55 on January 08, 2012, 04:38:09 am
Elgan,
Your initial unhandled exception sounds very similar to the problem that I was having.  Please try defining
Code: [Select]

_HAS_ITERATOR_DEBUGGING=0

under the project properties as a C++ preprocessor define and see if that fixes your problems.
Title: SFGUI
Post by: Tank on January 08, 2012, 08:54:54 am
Check this (http://sfgui.sfml-dev.de/guide/getting_started/building_from_source) and this (http://sfgui.sfml-dev.de/faq#cmake_find).

binary1248's guide will work too, however it's quite complicated and not the CMake-way of doing it :D.
Title: SFGUI
Post by: Elgan on January 08, 2012, 03:33:54 pm
Woo! thank you !
build sfgui-s-d.lib

Right:

SFML_STATIC
SFGUI_STATIC
SFGUI_EXPORTS
_HAS_ITERATOR_DEBUGGING=0

and now it crashes here:
Code: [Select]


sf::Vector2f Engine::GetTextMetrics( const sf::String& string, const sf::Font& font, unsigned int font_size ) const {
[color=red]sf::Text text( string, font, font_size );[/color]
return sf::Vector2f( text.GetLocalBounds().Width, text.GetLocalBounds().Height );
}

call stack = http://imageshack.us/f/638/32141209.png/
Title: SFGUI
Post by: binary1248 on January 08, 2012, 04:46:25 pm
Tank updated the Hello World code on the website. Try compiling that. It shouldn't crash like it did before anymore.
Title: SFGUI
Post by: Elgan on January 08, 2012, 06:05:23 pm
works wonderful :)

Thank you for patience

edit:


but the function OnButtonClick does not run, at all

  button->OnClick.Connect( &OnButtonClick );

not connecting.


, ill play..
Title: SFGUI
Post by: Tank on January 08, 2012, 11:46:12 pm
Could you please do a 'cout' in the handler to see if it's really not called?
Title: SFGUI
Post by: Elgan on January 08, 2012, 11:50:01 pm
Quote from: "Tank"
Could you please do a 'cout' in the handler to see if it's really not called?


already tried, plus breakpoint, nope :\
Title: SFGUI
Post by: Tank on January 10, 2012, 09:03:47 pm
Really strange. We're using fast delegates which were made possible using a LOT of hacks for various compilers, however there weren't issues with MSVC10 yet.

Just to make sure: Would you  mind uploading your full project somewhere so we can check?
Title: SFGUI
Post by: Elgan on January 10, 2012, 09:12:48 pm
Quote from: "Tank"
Really strange. We're using fast delegates which were made possible using a LOT of hacks for various compilers, however there weren't issues with MSVC10 yet.

Just to make sure: Would you  mind uploading your full project somewhere so we can check?


can't reproduce?

no worries, though it happens with the tutorial code, just 1 cpp file.... ill upload once ive written my chem up.

the code however is exactly that of the new tutorial. ....

also the lib compiled with no problems..


....also it is Visual Studio 2008
Title: SFGUI
Post by: Elgan on January 10, 2012, 11:31:37 pm
http://www.2shared.com/file/SFDcoOyd/sftest.html

think that's all, sorrya bout dlls, has static linking :\
Title: SFGUI
Post by: Tank on January 11, 2012, 06:14:07 pm
Quote
the code however is exactly that of the new tutorial. ....

It's not. In your source file it shows:

Code: [Select]
button->OnClick.Connect( OnButtonClick );

But in the "Hello world" examples you've got:

Code: [Select]
button->OnClick.Connect( &OnButtonClick );

Please check if that's causing the problem.
Title: SFGUI
Post by: Elgan on January 11, 2012, 11:41:04 pm
no sorry that was me messing about.

it was exactly the same and did not work, I rewrote that and some other lines before posting but just missed that as it compiled ok.


with it fixed..and exactly the same as the tutorial.........it does not "connect" still.

Edit: just double checked.....nope, not working, if I have time ill even video it, but its doing nothing....then copied tutorial code, copy paste...nothing.

maybe ill try redoing the .lib :S
Title: SFGUI
Post by: Elgan on January 12, 2012, 12:33:00 am
Found it!

Thanx, I rechecked the options and it was exporting it!....removed that and works, thanx for support and patience..........finally can move on...
Title: SFGUI
Post by: Tank on January 13, 2012, 08:46:33 am
Ha! ;) Good luck. ;)
Title: SFGUI
Post by: BlueMagic on January 23, 2012, 07:01:35 am
Everytime that I leave an example, it crashes. Is that normal?
Title: SFGUI
Post by: binary1248 on January 23, 2012, 01:25:39 pm
Quote from: "BlueMagic"
Everytime that I leave an example, it crashes. Is that normal?


Let me try to practice my fortune telling skills...

mmm...

You have an AMD/ATI graphics card?

And... you link to SFML dynamically?
Title: SFGUI
Post by: BlueMagic on January 23, 2012, 05:23:17 pm
Quote from: "binary1248"
Quote from: "BlueMagic"
Everytime that I leave an example, it crashes. Is that normal?


Let me try to practice my fortune telling skills...

mmm...

You have an AMD/ATI graphics card?

And... you link to SFML dynamically?


lol, yes and yes. Nice skills. I read a couple of pages but didn't see any mention of it, sorry. Is it going to be fixed or what can we do to fix it?
Title: SFGUI
Post by: victorlevasseur on January 23, 2012, 07:22:45 pm
The SFML ATI bug is already fixed, isn't it ?
Title: SFGUI
Post by: binary1248 on January 23, 2012, 10:22:09 pm
Quote from: "victorlevasseur"
The SFML ATI bug is already fixed, isn't it ?


http://www.sfml-dev.org/forum/viewtopic.php?t=4741
Title: SFGUI
Post by: raycrasher on January 25, 2012, 07:32:32 am
Hello,

Is there a way to use sf::Sprite as the image of a button? See, I have a bunch of sprites already loaded from a giant texture, and it currently looks like if I use sfg::Image I have to load that texture again.

I'm currently looking in the source, maybe I'll add a constructor to sfg::Image that accepts an sf::Sprite.

Thank you for your hard work in SFGUI!
Title: SFGUI
Post by: binary1248 on January 25, 2012, 01:14:31 pm
Internally sfg::Image stores both a copy of the sf::Image and the sf::Texture associated with that Image due to the fact that if you wanted to retrieve the sf::Image used by the sfg::Image it would have to construct a new sf::Image from the sf::Texture anyway. Sure this copying takes up more memory, but the idea is that you can create an sf::Image, use it in an sfg::Image and let it go out of scope so the only copy of it resides in the sfg::Image. What you could do in your case is create temporary sf::Images from your sf::Sprite by getting it's sf::Texture and TextureRect and passing it to the sfg::Image constructor. It will make a copy of it and you can forget about the temporary. This behavior will change in the next version of SFGUI anyway for performance reasons so I wouldn't invest time in trying to make Widgets work with arbitrary SFML objects.

Hope I could help.
Title: SFGUI
Post by: raycrasher on January 26, 2012, 12:00:30 pm
Thank you. I guess I'll just have to live with the increased memory requirements, at least until the next SFGUI release. Thanks for the help!
Title: SFGUI
Post by: Elgan on January 26, 2012, 12:07:11 pm
Entry.onkeyPress?

this is nice, very immature right now though.  Does it not exist, or do I need to add it?
Title: SFGUI
Post by: binary1248 on January 26, 2012, 04:26:06 pm
Quote from: "Elgan"
Entry.onkeyPress?

this is nice, very immature right now though.  Does it not exist, or do I need to add it?


http://sfgui.sfml-dev.de/doxygen/classsfg_1_1Entry-members.html

I stress once again, it is worthwhile reading the documentation when working with SFGUI. It can be found at the website: http://sfgui.sfml-dev.de
Title: SFGUI
Post by: Elgan on January 26, 2012, 06:25:12 pm
I see,. they inherit the widget ones too...entry just has 1 extra

I think it would be great to pass the key , I'm finding it difficult to detect key presses ..the function fires fine, but then how can I poll the ready polled event?
Title: SFGUI
Post by: binary1248 on January 26, 2012, 07:00:53 pm
Look in the event you passed to HandleEvent? It is the same one that fires OnKeyPress.
Title: SFGUI
Post by: BlueMagic on January 26, 2012, 10:37:37 pm
So there's no way to eliminate that error since it's pretty much caused by SFML, right? Or does linking statically eliminate it completely?
Title: SFGUI
Post by: binary1248 on January 27, 2012, 12:39:17 am
Quote from: "BlueMagic"
So there's no way to eliminate that error since it's pretty much caused by SFML, right? Or does linking statically eliminate it completely?


As Laurent indirectly implied in his post, there are 3 options.

Title: SFGUI
Post by: BlueMagic on January 27, 2012, 12:45:06 am
To not use the default font means to load a font by myself and use that manually, right? I wouldn't have to touch any SFML settings or anything? I'm not very familiar with using fonts and text in SFML.
Title: SFGUI
Post by: binary1248 on January 27, 2012, 01:03:14 am
It would mean not calling sf::Font::GetDefaultFont() yourself or leaving the Font property of the widgets blank (which causes them to use the default font automatically). What this also means is, as you already said, that you will have to load a font from a source (file, memory etc.) and use that instead for drawing your SFML stuff and for SFGUI widgets.
Title: SFGUI
Post by: Laurent on January 27, 2012, 07:59:05 am
Quote
I don't know if this counts but... you could try your best to convince Laurent to invest more time into looking into the bug

I will, but not for SFML 2.0.
Title: SFGUI
Post by: Tank on January 28, 2012, 11:20:14 am
Changes:


Besides of that a lot of minor changes have been made internally. We encourage every SFGUI user to checkout the new version and REPORT ANY ERRORS you may encounter. All changes have been applied to master.

There's still a crash at exit when you link dynamically on Windows. The cause is SFML's default font unloading after the context is destroyed. We can't really do anything against it except fixing SFML.
Title: SFGUI
Post by: Laurent on January 28, 2012, 11:36:15 am
Quote
Implemented own OpenGL renderer, SFML isn't used for most of the rendering anymore. (more than 200% performance increase; e.g. on my machine I get 3,600+ FPS instead of 1,200)

Have you tried SFML's vertex array? 1200 FPS was with which implementation?
By the way, you my opinion about such high FPS numbers for benchmarks ;)
Title: SFGUI
Post by: Tank on January 28, 2012, 11:53:48 am
Quote
Have you tried SFML's vertex array? 1200 FPS was with which implementation?

With client-side vertex arrays. :)

Quote
By the way, you my opinion about such high FPS numbers for benchmarks

I know, but the less time an external dependency/library takes, the better in my opinion.
Title: SFGUI
Post by: Tank on January 28, 2012, 11:54:33 am
And and btw: Nightly builds (http://sfgui.sfml-dev.de/download) have been updated (latest SFGUI + SFML2).
Title: SFGUI
Post by: Elgan on January 28, 2012, 02:09:07 pm
performance increase sounds fantastic ;)

thank you
Title: SFGUI
Post by: binary1248 on January 28, 2012, 03:02:28 pm
Quote
By the way, you my opinion about such high FPS numbers for benchmarks


Software libraries display an unusual property:

1 + 1 = 0.5 (in the worst case)

or in our case more like 1000 FPS + 1000 FPS = 700 FPS or something.

If you were to use 10 libraries which stem from developers who stop optimizing at 1000 FPS what do you think is going to happen to your awesome game? Of course it will run at 1000 FPS too right? Or else they would have optimized it more... because the FPS drop must come solely from their library and they only care about the use case where their library is used by itself.. which would make so much sense with SFGUI.

Sure.. if SFML or SFGUI was used purely by themselves, I would share your opinion 100%, but I didn't find any hidden clause somewhere which tells users that is the only way to make their next awesome game. We (at SFGUI) want the user to get maximum performance no matter how many libraries they want to use and how their performance is, be it 1 or 100. Therefore our view regarding performance.

Hope I could enlighten some people who cared to read my wall of text.
Title: SFGUI
Post by: Laurent on January 28, 2012, 06:45:13 pm
Hu... I was not talking about the optimization, which is always a good thing of course. I was saying that using such high numbers were irrelevant to show optimization results. We already talked a lot about this ;)

Sorry if it was not clear.
Title: SFGUI
Post by: Laurent on January 28, 2012, 06:47:28 pm
Quote
With client-side vertex arrays

So you had time to test the new API before switching to OpenGL. Was it better (performances and usage) than the old one? I'm interested to see how it performs for GUI systems :)
Title: SFGUI
Post by: Laurent on January 28, 2012, 07:15:10 pm
By the way, since a GUI library needs to draw many small entities, it's very close to what I need to optimize in SFML. So if you feel like there are optimizations that I could apply to SFML, don't hesitate to share.

Sorry for triple posting :lol:
Title: SFGUI
Post by: binary1248 on January 28, 2012, 07:17:19 pm
Quote from: "Laurent"
I was saying that using such high numbers were irrelevant to show optimization results.


Well regarding optimization results, the more the better right? So if you have a library that runs at 2000 FPS instead of 1000 FPS it is sure to run faster on a slower system, say from 100 FPS to 200 FPS? Until you are sure that your GPU and CPU are both fully loaded you can always optimize no matter what the FPS value is. Optimization is not about maximizing the absolute FPS you get on one system, but rather eliminating the bottlenecks on all systems at the same time to ensure it will run faster (meaning more FPS regardless of the system) on all systems instead of at a given FPS value on one given system.

Therefore high numbers are indeed relevant, they show that a certain optimization does have a positive effect. And that effect will carry over to all systems, not only my own. Not everybody has a modern (in the last 2 years) GPU, and Tank's +2400 FPS might translate to e.g. +100 FPS from 50 FPS for them, which is very desirable.

You have to open up for a wider range of hardware if you really want to support OpenGL ES ;)
Title: SFGUI
Post by: Laurent on January 28, 2012, 07:38:28 pm
You don't get it. Let me explain again what I mean.

At 3600 FPS, one frame takes less than 300 microseconds to render. At such low durations, anything takes a significant part of the result, even event/window handling -- and basically, everything that happens only once per frame and that you don't want to see in the result. Even running a music player in the background could make a difference.

In one frame you draw many widgets, but you also do a lot of small things that are irrelevant to what you want to optimize. If you want to focus on the widgets themselves, you must draw many more of them so that the rest becomes really negligible. In my opinion, you must be below 100 FPS if you want to be credible.

Or... you should just say "overall performance improvement of ~200%" and not give too many details ;)
Title: SFGUI
Post by: binary1248 on January 28, 2012, 08:48:22 pm
Yeah, I know that anything running on my computer could skew the results. I even actually get much lower FPS when running other CPU or GPU intensive applications at the same time as testing. But when I test the real performance of the library I make sure that my test environment is as clean as possible a.k.a CPU and GPU load < 5% which is a decent margin of error.

Browsing the web or using "typical" everyday applications implies the same window management / event handling as anything else running on my computer and that doesn't even load my CPU past 5% which means the same OS overhead would apply to an SFML application too. Which leaves the other 95% of usage purely to the "essential" part of the app (drawing and what not).

We could just shove 1000 buttons into our ScrolledWindow and turn off culling to purposely get the FPS down to 100 FPS if that's what it takes to get reliable test results. But why do so if we can see the difference at much higher FPS values?

Being a hobby physicist I just have to throw in an example:

Consider you want to measure the speed of light. And you would do so by measuring the duration it takes for a laser pulse to travel a certain distance.

You could measure it by getting a 10KM long fiber optic cable and sending a pulse through it and measuring the time it takes through that. Or you could get a 10M long fiber optic cable and measure the time it takes to travel through that with a high precision measuring device. You would resort to the first method because it would seem less susceptible to interference and margin of error of the time measuring device. But because we made sure the test environment was clean and the same in both cases we can also resort to the second method.

The key when testing is making sure you can reproduce your results, which in turn means the environment is fully understood and taken into account. The FPS values stated here are reproducible between system restarts and the relative FPS gain among the testers is also consistent which means that the FPS values themselves are in fact a reliable method of measuring performance, even at such high values.

Also worth reading: Amdahl's law (http://en.wikipedia.org/wiki/Amdahl%27s_Law#Speedup_in_a_sequential_program)
Title: SFGUI
Post by: Tank on January 28, 2012, 09:25:16 pm
Quote
So you had time to test the new API before switching to OpenGL. Was it better (performances and usage) than the old one? I'm interested to see how it performs for GUI systems

Yep, we also took the time to see how it performs. It was definitely better performance. Before the new graphics API the highest FPS we could get was ~400 (SFGUI test application), with our custom culling and using display lists we could get it up to ~1,600 FPS.

The new graphics API put out 1,200 FPS, without custom culling and without display lists. So it was still slower than the old API together with our optimizations, but faster without them.

Quote
By the way, since a GUI library needs to draw many small entities, it's very close to what I need to optimize in SFML. So if you feel like there are optimizations that I could apply to SFML, don't hesitate to share.

Basically: VBO. The whole GUI is stored in one single VBO, together with a texture atlas for one single texture (this may change in the future as there're limits regarding the maximum texture dimensions). Then there're a lot of matrix operations and other OGL calls that we can save because we're only calling what's indeed needed.

I think (binary1248 can give better explanations as he did the renderer) the biggest benefit is saving the bus (to GPU) the trouble by avoiding sending buffers (vertices, texture coordinates and colors) every frame.

The optimizations are actually shared; SFGUI is open source. ;) It's quite easy to see how the renderer works (check Renderer.cpp and Primitive.cpp at first, most important files regarding the rendering).
Title: SFGUI
Post by: Elgan on January 28, 2012, 09:31:18 pm
This is very fun reading..there is software which will measure performances.


maybe it would be fun to make a test benchmark thingie for SFML aps of sorts...not sure how it would work right now..

fps, and external measuring memory and ..hm whatever else.
Title: SFGUI
Post by: binary1248 on January 28, 2012, 10:12:12 pm
Good idea... Laurent can decide what he deems worthy to benchmark in every version of SFML ^^. Then just write a spec and that will be the standard of testing. Such areas could be e.g. text rendering, sprite rendering, shape rendering etc.
Title: SFGUI
Post by: Laurent on January 28, 2012, 11:53:49 pm
Quote
The key when testing is making sure you can reproduce your results, which in turn means the environment is fully understood and taken into account.

I'm pretty sure that you don't fully understand how SFML can impact your performances. For example, there's a bug in event handling on Windows that will slow down some applications randomly. However it happens once per frame so if your test application is really loaded it will hardly make a difference on the final result.

I'm not saying that your tests are flawed, I'm even sure that they are strictly executed and interpreted. But that's not the most efficient way of testing things, and some other people might not trust your results.

Quote
It was definitely better performance. Before the new graphics API the highest FPS we could get was ~400 (SFGUI test application), with our custom culling and using display lists we could get it up to ~1,600 FPS.

The new graphics API put out 1,200 FPS, without custom culling and without display lists. So it was still slower than the old API together with our optimizations, but faster without them.

Thanks for the feedback.

Quote
Basically: VBO.

I was afraid you would say that :D
A GUI is a static thing, so I guess that VBO are perfect. In SFML things are more complicated, I cannot assume any particular usage. For example, many people use a single dynamic sprite to draw everything in their game. I must design and implement things as if every property of every entity could change every frame.
At least, with the new API, people who know a little about graphics programming can write efficient code with SFML. They're no longer stuck with slow sprites.

Quote
The optimizations are actually shared; SFGUI is open source.

True :)
Title: SFGUI
Post by: binary1248 on January 29, 2012, 12:41:00 am
Quote
For example, there's a bug in event handling on Windows that will slow down some applications randomly.


Interesting... another bug I didn't know about.

Quote
I must design and implement things as if every property of every entity could change every frame.


That's exactly what the GL_STREAM_DRAW usage hint was designed for. It tells the GPU that it can expect buffer data to change between every draw call (even multiple times). The difference is that with a VBO which you update completely every frame the data is in a single buffer on the card. Think of it like calling new int; 1000 times and calling new int[1000];. The second variant would probably complete faster for the exact same reasons. And if you "prepare" the data to be as GPU friendly as possible, it will reward you appropriately.

"Prepare" would mean things like:

What one needs to look for are values which the GPU probably has to calculate every frame but stay exactly the same. They can be calculated when needed on the CPU and passed to the GPU "prepared" so it can save a lot of effort putting those pixels on the screen.

If you want an extreme (and still quite buggy) example of how I prepare data for the GPU, have a look at the texture preblending we do in the new Renderer. It offloads the blending from the GPU to the CPU under the assumption that the blended pixel values stay the same over all frames. I tried it out because 1. GPUPerfStudio was telling me that the GPU was stalling on buffer operations and 2. because I was crazy enough and had too much time. It seemed to harvest more performance and can work under the right circumstances.

The key is really to make a library so intelligent it knows how it can optimize the users data by itself in every situation.

For those who are curious, during the implementation of the new renderer I used gDebugger, GPUPerfStudio, valgrind and of course faithful gprof.
Title: SFGUI
Post by: Laurent on January 29, 2012, 09:38:02 am
Quote
That's exactly what the GL_STREAM_DRAW usage hint was designed for

My tests showed that locking/updating/unlocking a GL_STREAM_DRAW VBO is still slower than a vertex array, which is already slower than immediate mode in such a context.

Quote
The difference is that with a VBO which you update completely every frame the data is in a single buffer on the card. Think of it like calling new int; 1000 times and calling new int[1000];

Does it mean that you create one single big VBO and then "allocate" your widgets' geometries inside it with a custom algorithm? I never succeeded to write such an implementation, because writing an efficient allocator is really complex.

Quote
Converting your geometry data to draw using one primitive type

SFML is not high-level enough, it explicitely allows one to choose its primitive type.

Quote
Reducing state changes (less texture binds, etc.) by batching and reordering the draws on CPU without influencing the final outcome of the frame.

Again, SFML is not high-level enough, it must do immediate drawing so no batching is possible. I optimize state changes and pre-transform small entities on the GPU but I feel like this is the maximum that I can do.

With a GUI, the order is defined by the parent-child relationship, you can easily have a scenegraph behind the scenes and benefit from all the nice optimizations that such a data structure allows. This is hardly applicable to SFML.

Quote
The key is really to make a library so intelligent it knows how it can optimize the users data by itself in every situation.

Is it your feeling about SFML too, knowing that it provides low-level primitives and doesn't know what the user will do with them?
Title: SFGUI
Post by: Laurent on January 29, 2012, 10:56:38 am
I've had a look at Renderer.cpp, and now I understand your rendering strategy (you can ignore my related question above). It is definitely not applicable to SFML because I can't batch everything and delay all the rendering until the end of the frame.

I've seen some really nice ugly hacks and the even nicer comments associated to them about SFML. If you want to talk about these issues I'm here ;)
Title: SFGUI
Post by: binary1248 on January 29, 2012, 01:09:34 pm
Like I said, a library has to recognize opportunities to optimize and do it the best it can. Of course you can't optimize in exactly the same way for every single use case there is.

For example some people might not make use of VertexArrays or custom primitive types for whatever reason. Then you can assume that whatever he draws every frame, sprites, text, etc. can be broken down into triangles.

You could also for example batch text draws together. Say the user draws multiple sf::Texts after each other (very common from what I've seen) with the same sf::Font (face and size same), you can also batch those together. It saves you from stopping to check whats next to draw only to find out that it's exactly the same kind of data that you previously drew and even using the same texture.

Quote
My tests showed that locking/updating/unlocking a GL_STREAM_DRAW VBO is still slower than a vertex array, which is already slower than immediate mode in such a context.
...
It is definitely not applicable to SFML because I can't batch everything and delay all the rendering until the end of the frame.


Well correct me if I'm wrong, but the user won't see anything on the screen until he calls Display on his window anyway. So whether the drawing takes place right where he calls it or is saved and performed in the same order right before the buffer is swapped, I don't see the difference. The big one though is that you would transfer your data in bigger chunks which is where VBOs start to shine. As long as data runs around host memory or GPU memory it stays fast. When it has to run across the PCIe bus, and that too many times per frame, it becomes the bottleneck which is what you are probably seeing in your comparison between Vertex Arrays and VBOs.

VBOs also don't perform too well if they are too small. So to use them properly you would have to serialize a lot of that primitive data together and draw multiple times using that 1 buffer. I also don't have to stress that VBOs don't have to be drawn completely in 1 pass. They can hold data for different primitive types. Heck they can hold completely different data sets together one after the other. Whatever you can draw using multiple Vertex Arrays you can draw using 1 VBO and multiple draw calls.
Title: SFGUI
Post by: Laurent on January 29, 2012, 07:02:28 pm
Quote
You could also for example batch text draws together. Say the user draws multiple sf::Texts after each other (very common from what I've seen) with the same sf::Font (face and size same), you can also batch those together. It saves you from stopping to check whats next to draw only to find out that it's exactly the same kind of data that you previously drew and even using the same texture.

I already have a state cache, I only set the states that changed between two Draw calls.

Quote
Well correct me if I'm wrong, but the user won't see anything on the screen until he calls Display on his window anyway. So whether the drawing takes place right where he calls it or is saved and performed in the same order right before the buffer is swapped, I don't see the difference.

Good point. That reminded me of something, so I checked and found that two years ago I already tried to implement batching in SFML 2.
Here is what I said on 19/01/2010:
Quote
The automatic batching system was great, but after using it for a while and collecting feedbacks, I realized that it was creating new problems that were very tricky to solve.

Unfortunately I don't remember what these problems were.
Title: SFGUI
Post by: binary1248 on January 29, 2012, 09:00:44 pm
Quote from: "Laurent"

I already have a state cache, I only set the states that changed between two Draw calls.


State changes aren't the only things you can save on although they make up a big piece of the time it takes to draw a frame. Draw calls are almost as expensive overhead-wise as state changes. Drawing 10 Sprites/Rectangle shapes for example requires vertex data for just 40 vertices but causes more than 40 OpenGL calls to be made.

Quote from: "Laurent"

Good point. That reminded me of something, so I checked and found that two years ago I already tried to implement batching in SFML 2.
Here is what I said on 19/01/2010:
Quote
The automatic batching system was great, but after using it for a while and collecting feedbacks, I realized that it was creating new problems that were very tricky to solve.

Unfortunately I don't remember what these problems were.


Well... you did change the drawing routines completely and don't use glBegin() glEnd() anymore. So maybe those problems won't carry over to the new drawable API. A link to that thread would be nice.
Title: SFGUI
Post by: Laurent on January 29, 2012, 10:25:31 pm
Quote
Well... you did change the drawing routines completely and don't use glBegin() glEnd() anymore. So maybe those problems won't carry over to the new drawable API.

This code had implementations for VBO, VA and IM.

Thread:
http://www.sfml-dev.org/forum/viewtopic.php?t=2063
(not very helpful because that's where I say that I removed the batching stuff)

More useful, the last revision where it was used:
https://github.com/SFML/SFML/tree/8ba9495c02f95dbff8aee44121a13f999234fb2f
Title: SFGUI
Post by: binary1248 on January 30, 2012, 01:43:12 am
From what I can tell reading through the source, it would have been bottlenecked by the CPU instead of the GPU. Thus whether you used VAs, VBOs or IMs it probably wouldn't make any significant difference. Your usage of the word "Batch" to describe the class containing the data for a single drawable is also kind of misleading. They weren't really batched data and so could not profit from batching at all.

Your idea of uploading data into a single buffer and drawing all at once at the end was good. HOWEVER, if you only draw the data one object at a time they will be, as you saw, hardly any better than VAs or even IM.

It would have probably made a big difference if you had stored more relevant data inside the Renderer object and let it manage drawing the objects itself when the time came. That way it would have been able to truly batch multiple objects together if it saw the possibility, saving not only a little GPU time but a massive amount of CPU time. Contrary to what people think most state changes and matrix ops take part on the CPU in the driver and the data gets sent in it's raw form to the GPU. Thus if the CPU is already busy going through all the batches every frame, the FPS will be hurt even more by redundant state changes which were abundant in that version.

Because you changed SFML a lot since then and cache states more effectively now and even use VAs as the primary drawing method, it would be nice to see how that old concept would fare in the current implementation.

And I'm curious, were these problems you speak of bugs/glitches or the flexibility/limitation kind of problems? I couldn't find any reports of problems related to the old drawing method while searching through those old threads.

Quote
I've seen some really nice ugly hacks and the even nicer comments associated to them about SFML. If you want to talk about these issues I'm here ;)


Wishlist (among other things to make SFGUI less "hacky"):
Title: SFGUI
Post by: Tank on January 30, 2012, 07:55:17 am
Quote
In SFGUI we have our lovely test app

Hehe. The problem with that is that the app itself changes a lot over time. For benchmarking something finished should be used. ;)
Title: SFGUI
Post by: Laurent on January 30, 2012, 08:18:35 am
Quote
From what I can tell reading through the source, it would have been bottlenecked by the CPU instead of the GPU. Thus whether you used VAs, VBOs or IMs it probably wouldn't make any significant difference.

It tried: IM > VA > VBO.

Quote
Your usage of the word "Batch" to describe the class containing the data for a single drawable is also kind of misleading. They weren't really batched data and so could not profit from batching at all.

Your idea of uploading data into a single buffer and drawing all at once at the end was good. HOWEVER, if you only draw the data one object at a time they will be, as you saw, hardly any better than VAs or even IM.

I was accumulating vertices inside a sf::Batch until one state changed, so if drawing many sprites using the same texture, for example, I would end up drawing a single big chunk of geometry at the end.

Quote
Because you changed SFML a lot since then and cache states more effectively now and even use VAs as the primary drawing method, it would be nice to see how that old concept would fare in the current implementation.

I'll probably give it another try, yes.

Quote
And I'm curious, were these problems you speak of bugs/glitches or the flexibility/limitation kind of problems? I couldn't find any reports of problems related to the old drawing method while searching through those old threads.

I can't remember :(

Quote
1. Some way to identify/compare fonts among each other (name of the face or something).

In most use cases this will be useless: one can store the name when it loads the font, or use the sf::Font pointer as an identifier. Problems arise when you write a middleware, like SFGUI, and have no control on font instances. What kind of other use case could it be useful for?

Quote
2. Some way to tell SFML to wipe it's vertex cache.

I know that it's not very efficient, but currently SFML is not designed to be mixed with OpenGL this way. One must call Push/Pop/ResetGLStates in order to avoid messing up internal states. Supporting custom OpenGL commands in the middle of SFML rendering would require more work on my side, and probably a slightly different public API.
Out of curiosity, is it really a performance killer to call ResetGLStates once per frame?

Quote
3. Since you allow asking for a depth/stencil buffer, it would be nice to be able to clear those with RenderTarget::Clear() too instead of just the color. Now users have to resort to calling glClear() themselves which is horribly expensive.

I understand. However it would be weird to have something related to the depth buffer in the graphics module, which doesn't deal with depth at all.

Quote
4*. A standard benchmark spec that encompasses all areas of SFML to use as a performance measurement tool while trying to optimize SFML. This is one of those crucial things that I and others would need to know to experiment with making SFML faster.

I could show my own test app as a starting point, and maybe we could improve it together?
Title: SFGUI
Post by: Nexus on January 30, 2012, 09:18:10 am
I'm not sure if it's related, but there have been some bugs with the old render cache, e.g. this one (http://www.sfml-dev.org/forum/viewtopic.php?t=3774).
Title: SFGUI
Post by: Laurent on January 30, 2012, 09:53:50 am
Nop, this one is related to the state cache that was implemented after the batch renderer. Everything that involves sf::Renderer is the new implementation. The old one was using a sf::RenderQueue.
Title: SFGUI
Post by: binary1248 on January 30, 2012, 12:16:36 pm
Quote
In most use cases this will be useless: one can store the name when it loads the font, or use the sf::Font pointer as an identifier. Problems arise when you write a middleware, like SFGUI, and have no control on font instances. What kind of other use case could it be useful for?


Besides letting others manage the font resource themselves, probably none. I had an implementation with pointer comparisons, however that turned out to be a problem because GetDefaultFont() returns a reference, and to stay consistent all our fonts are passed around as references. We could just get the address of the sf::Font instance but that wouldn't work on temporary objects placed somewhere on the stack.

Quote
Out of curiosity, is it really a performance killer to call ResetGLStates once per frame?


We already minimized the state changes needed to be done when rendering the GUI. As such we want to manage the setting and resetting of the states ourselves and omit having to call ResetGLStates to reset things we didn't even touch. Calling ResetGLStates every frame was resulting in noticeably less performance.

Quote
but the best results will be achieved if you handle OpenGL states yourself (because you know which states have really changed, and need to be saved and restored)


That's what we want ;). And since when was a cache part of the OpenGL state machine? :P

Quote
I understand. However it would be weird to have something related to the depth buffer in the graphics module, which doesn't deal with depth at all.


Well you already let people create a depth buffer at Window creation although SFML doesn't make use of it itself. Keeping SFML "depth free" is therefore futile ^^.

Quote
I could show my own test app as a starting point, and maybe we could improve it together?


Would be a good starting point.
Title: SFGUI
Post by: Laurent on January 30, 2012, 12:31:01 pm
Quote
We could just get the address of the sf::Font instance but that wouldn't work on temporary objects placed somewhere on the stack.

Your current implementation, which stores the font face pointer, breaks on this use case too, right?
In fact what's the difference between storing the internal font face pointer, and the pointer to the sf::Font instance?

Quote
Calling ResetGLStates every frame was resulting in noticeably less performance.

How many percents? ;)

Quote
That's what we want . And since when was a cache part of the OpenGL state machine?

Obviously this part is not yet very well supported in SFML :D
It definitely required more work. It would be really awesome if SFML and OpenGL could nicely be mixed together transparently.

Quote
Well you already let people create a depth buffer at Window creation although SFML doesn't make use of it itself. Keeping SFML "depth free" is therefore futile ^^.

The creation of the depth buffer is part of the window module, which clearly targets OpenGL and thus must provide features such as a depth buffer.
Adding a function to the graphics API would be weird.
But I understand that it's an issue.

Quote
Would be a good starting point.

I'll try to post it as soon as possible. It needs a little work before I can post it.
Title: SFGUI
Post by: binary1248 on January 30, 2012, 12:46:41 pm
Quote
Your current implementation, which stores the font face pointer, breaks on this use case too, right?
In fact what's the difference between storing the internal font face pointer, and the pointer to the sf::Font instance?


The answer to that lies in your sf::Font copy constructor :)

Quote
How many percents?


Can't remember exactly, but seeing the amount of code I wrote to avoid doing that, it must have been >10%.
Title: SFGUI
Post by: Laurent on January 30, 2012, 01:07:11 pm
Quote
The answer to that lies in your sf::Font copy constructor

So you can handle copies of the same sf::Font instance, but not multiple sf::Font instances that would load the same font. Fair enough.

But to be honest, if FreeType allowed a font face to be copied, I would do a deep copy instead of using reference counting. The current implementation is just a workaround.

Anyway, providing more font information in sf::Font could be a good idea.
Title: 613 Image buttons
Post by: raycrasher on February 11, 2012, 05:47:36 am
Hello,

I am having some problems trying to create a window where I can display 618 image buttons for the user to choose from.

Trial 1
Loaded the 618 sprites into buttons, and added said buttons to a window. Result: compiles ok, loads ok (according to debugging), but hangs when the GUI updates or displays. 618 buttons loaded without images works though. Loading only a few sprites also works ok.

Trial 2
Loaded the whole spritesheet texture instead of individual sprites; I was thinking of drawing the buttons (with transparent background) over the image, like hot-spots. Displays ok, but I have a 1024x1024 spritesheet, and the window really needs to scroll in order to show the entire sheet. Besides, this is suboptimal, since I cannot sort the sprites according to category.

Trial 2.5
Tried using ScrolledWindow: Runs but does not display the texture. Then I noticed ScrolledWindow looks and feels like a control since it can't be dragged around, so I added it to a regular Window. Crash. Back to Trial 2.

Help! :(
Title: SFGUI
Post by: binary1248 on February 11, 2012, 06:03:18 am
The only acceptable solution would be the first one. At the moment SFGUI is limited by the maximum texture size of the graphics card of the system it is running on. However you did mention that the spritesheet was (only) 1024x1024 which should fit in any not to ancient graphics card without issues.

I'm curious, does it also not work if you reduce the amount of buttons to say... 200 or 100? Or does it only not work at 618 buttons? The latter would indicate the limitation I mentioned earlier. The former would mean another bug somewhere. IIRC SFML should complain about OpenGL not being able to do stuff if you run it in debug mode. Always remember to check your console output when running something during development.
Title: SFGUI
Post by: raycrasher on February 11, 2012, 06:29:28 am
Thanks for the quick reply!

I tried loading 128 buttons with images - hangs. Each would be about 10x10 to 70x70 pixels.

I will now try another variant of Trial 1 - Create a TabStrip-like control (Notebook, is it?), and separate the sprites by category into separate pages. Just need to know how would I implement scrolling through said buttons, since each category will have about 40 sprites each minimum. I'm looking at the test.cpp example as I type this, and yes, ScrolledWindow would be the way.

*copypasta mode* :D

Anyway, I was wondering why you used your own sfg::Image for image display - isn't sf::Sprite sufficient?
Title: SFGUI
Post by: binary1248 on February 11, 2012, 06:57:26 am
sfg::Image is a SFGUI widget containing an Image. As such it can be manipulated in any way a widget would normally be manipulated (moved, resized, themed etc.). Internally it saves the image texture as an sf::Texture and the raw image data as an sf::Image. Using sf::Sprite doesn't come into question because of the new (optimized) way we render the GUI in the latest version. We take care of OpenGL ourselves and thus can refrain from using SFML itself for drawing.
Title: SFGUI
Post by: Mars_999 on February 18, 2012, 11:20:36 pm
I just stumbled across this great project.

Now I am curious to know how can one skin/theme the GUI? or load buttons that are textured vs. a solid color....

Thanks!
Title: SFGUI
Post by: Tank on February 19, 2012, 01:23:02 pm
Mars_999: Check the SFGUI forum for the reply.
Title: SFGUI
Post by: Mars_999 on February 19, 2012, 03:22:17 pm
Quote from: "Tank"
Mars_999: Check the SFGUI forum for the reply.


Thanks! Yeah the auto inform isn't working....
Title: SFGUI
Post by: Tank on March 13, 2012, 02:07:48 pm
Updated to SFML's new naming conventions. Nightly builds will follow.
Title: SFGUI
Post by: Mars_999 on March 13, 2012, 11:08:47 pm
Thanks for the heads up!!!
Title: Re: SFGUI
Post by: Meteorhead on March 28, 2012, 07:46:28 pm
Hi!

I have read through the forum from the point on where crashes were mentioned at the end of applications, however no solution was mentioned, or the attempt to have it fixed. Is there anything to do to fix it from an end-user POV, such as myself? If I took it correctly staticly linked libs could do the tricks, but that is less elegant.
Title: Re: SFGUI
Post by: binary1248 on March 28, 2012, 08:12:18 pm
That depends on what kind of crash you mean. If you mean the GetDefaultFont() crash then the only way is to static link (this goes for any SFML project btw). If you mean the crash while static linking, then you have to grab the latest master and look at the usage of the SFGUI sfgui; guard variable. It is our current workaround for SFML's intolerance for OpenGL resources in static objects.
Title: Re: SFGUI
Post by: Meteorhead on March 29, 2012, 12:15:01 pm
I am talking about the crash, that happens when closing the application. I create an sf::Text object to draw an FPS counter which I keep updating with an instance of sf::String and when the application closes, it segfaults. All SFGUI samples behave this way, although I pulled master from both SFML and SFGUI just yesterday. Is there anything to do about this? I do not recall using getDefaultFont, but it might just occur that this function runs somewhere if I do not specify a specific font anywhere else.
Title: Re: SFGUI
Post by: Tank on March 29, 2012, 02:06:37 pm
BREW (the default rendering engine) uses getDefaultFont() if no other fonts are specified.

To avoid the crash build and link statically on Windows, both SFML and SFGUI.
Title: Re: SFGUI
Post by: Meteorhead on April 04, 2012, 05:18:28 pm
For some reason I cannot build SFGUI statically, neither can I build an SFML application using the statically built SFML libs that used to work before with the dynamic variants.

Using dynamic libraries, everything was fine. Tank suggested to build and link both SFML and SFGUI statically. Most likely the mistake is on my part, but when I try to build the same project that used to work with DLLs (SFML only just yet), even though I updated lib names in the "Linker->Input" property part to be:

sfml-main.lib;sfml-system-s.lib;sfml-window-s.lib;sfml-graphics-s.lib;opengl32.lib;glu32.lib;GLEW64.lib;%(AdditionalDependencies)"

when I compile my program it gives heaps of undefined external symbols looking like:

1>------ Build started: Project: SFML_GL_test, Configuration: Release x64 ------
1>Build started 2012.04.04. 16:39:30.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(299,5): warning MSB8004: Output Directory does not end with a trailing slash.  This build instance will add the slash as it is required to allow proper evaluation of the Output Directory.
1>InitializeBuildStatus:
1>  Touching "x64\Release\SFML_GL_test.unsuccessfulbuild".
1>ClCompile:
1>  main.cpp
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __cdecl type_info::type_info(class type_info const &)" (??0type_info@@AEAA@AEBV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __cdecl type_info::operator=(class type_info const &)" (??4type_info@@AEAAAEAV0@AEBV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>LIBCMT.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual class sf::Vector2<unsigned int> __cdecl sf::RenderWindow::getSize(void)const " (__imp_?getSize@RenderWindow@sf@@UEBA?AV?$Vector2@I@2@XZ)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl sf::RenderWindow::~RenderWindow(void)" (__imp_??1RenderWindow@sf@@UEAA@XZ)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl sf::RenderWindow::RenderWindow(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (__imp_??0RenderWindow@sf@@QEAA@VVideoMode@1@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IAEBUContextSettings@1@@Z)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl sf::View::View(class sf::Rect<float> const &)" (__imp_??0View@sf@@QEAA@AEBV?$Rect@M@1@@Z)


When I try to build SFGUI to make static libraries, I get the following in nmake:

Linking CXX static library lib\sfgui-s.lib
[ 84%] Built target sfgui
[ 85%] Building CXX object examples/CMakeFiles/Box.dir/Box.cpp.obj
Box.cpp
NMAKE : fatal error U1073: don't know how to make 'C:\Kellekek\SFML\lib\sfml-gra
phics.lib'
Stop.
NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft Visual Studio 10.0\VC\BIN\amd
64\nmake.exe"' : return code '0x2'
Stop.


I don't know why is it looking for sfml-graphics.lib when I told it in cmake that SFML was built statically, so I would think it should be looking for sfml-graphics-s.lib (which exists as expected in it's intended install location) Can someone tell me where I am going wrong?

Thank you for the help in advance,
Máté
Title: Re: SFGUI
Post by: eXpl0it3r on April 04, 2012, 05:36:03 pm
Make sure you do define SFML_STATIC and I think it's the same for SFGUI: SFGUI_STATIC
CMake should define those on its own, but maybe the CMake file is faulty. ;)
Title: Re: SFGUI
Post by: Meteorhead on April 04, 2012, 06:11:07 pm
I defined SFML_STATIC ahead of all includes, then there were lots of conflicting "already defined in..." messages. I had to use "Ignore Spcific Default Libraries" in "Linker->Input" by removing those responsible for conflicting defines:

MSVCRT;MSVCPRT

Plus I had to remove GLEW64.lib as a required input, as it was conflicting with sfml-graphics-s.lib. Now I only got a few unresolved external symbols, namely:


1>  main.cpp
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned __int64 __cdecl std::ctype<wchar_t>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@_W@std@@SA_KPEAPEBVfacet@locale@2@PEBV42@@Z)
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: wchar_t __cdecl std::ctype<wchar_t>::widen(char)const " (__imp_?widen@?$ctype@_W@std@@QEBA_WD@Z)
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: char __cdecl std::ctype<wchar_t>::narrow(wchar_t,char)const " (__imp_?narrow@?$ctype@_W@std@@QEBAD_WD@Z)
1>sfml-window-s.lib(WindowImpl.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl std::_Container_base12::~_Container_base12(void)" (__imp_??1_Container_base12@std@@QEAA@XZ)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::basic_istream<char,struct std::char_traits<char> >::read(char *,__int64)" (__imp_?read@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@PEAD_J@Z)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::fpos<int> __cdecl std::basic_istream<char,struct std::char_traits<char> >::tellg(void)" (__imp_?tellg@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAA?AV?$fpos@H@2@XZ)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::basic_istream<char,struct std::char_traits<char> >::seekg(__int64,int)" (__imp_?seekg@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@_JH@Z)
1>sfml-graphics-s.lib(ImageLoader.cpp.obj) : error LNK2001: unresolved external symbol __imp_ldexp
1>D:\ToBeSaved\Develop\SFML_GL_test\\bin\SFML_GL_test.exe : fatal error LNK1120: 8 unresolved externals
1>
1>Build FAILED.


Any ideas how to resolve this last issue?

ps.: am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.
Title: Re: SFGUI
Post by: eXpl0it3r on April 04, 2012, 06:42:47 pm
I defined SFML_STATIC ahead of all includes, then there were lots of conflicting "already defined in..." messages.

I'd say this is not the right approach.
I asume you're using Visual Studio, so there's an option under Project->[ProjectName]-Preferences->C/C++->Preprocessor->Preprocessor definitions
You should provide SFML_STATIC there.

Did you check the STATIC_STD_LIBS in the CMake configuration?
If so please make sure you're using the right standard libraries in your project.

And keep in mind do not mix debug and release libraries vs debug and release build modes!

am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.
One can not know everything and it takes its time to figure out how to build it.
Its pretty easy for me to build them, just uncheck BUILD_SHARED_LIBS (check STATIC_STD_LIBS if you want to use static standard libs), generate and build.

If you're not a fan of static libs why do you use them?
Title: Re: SFGUI
Post by: Meteorhead on April 04, 2012, 07:18:34 pm
If you read back a bit, then you'll see it's neccessary because SFGUI crashes on every application exit because of an issue that arises due to the way libs unload. Static linking can solve the issue.
Title: Re: SFGUI
Post by: binary1248 on April 04, 2012, 09:08:41 pm
When you get "already defined in..." messages regarding functions from the C runtime you shouldn't automatically choose to ignore specific libraries, otherwise the symbols won't be imported and you get errors such as in your second post. Most of the time the reason for "already defined in..." is actually that you are importing/using the wrong version of the C runtime somewhere in your build process.

See: http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx

Quote
ps.: am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.

Normally it should take only 5 minutes. It's a matter of determining how SFML was built (among other things if it uses static or dynamic C runtime), replicating those settings in the SFGUI CMake configuration and building SFGUI. Using different link settings ANYWHERE in your project (not only building SFML or SFGUI) will probably cause errors. Static linking is not any more complicated than dynamic linking is and you should be able to keep with the procedure you would go through to link dynamically too. The only thing I wouldn't touch is STATIC_STD_LIBS, neither in SFML nor SFGUI. MSVC doesn't really like it when you static link the runtime.

Quote
Plus I had to remove GLEW64.lib as a required input, as it was conflicting with sfml-graphics-s.lib.

Maybe Laurent should make it more obvious that GLEW is already included in sfml-graphics-s.lib.
Title: Re: SFGUI
Post by: eXpl0it3r on April 04, 2012, 09:33:10 pm
When you get "already defined in..." messages regarding functions from the C runtime you shouldn't automatically choose to ignore specific libraries, otherwise the symbols won't be imported and you get errors such as in your second post. Most of the time the reason for "already defined in..." is actually that you are importing/using the wrong version of the C runtime somewhere in your build process.

Well it's true that one has to be carefull about this, but it's true that MSVC complains a lot about the diffrent versions of the standard library, I think specially if you link them statically. Mostly they are just warnings though and the libs and the application will run without problems. So you end up excluding all the libs you actually don't want and VS strangly still includes.
For the diffrent libraries see http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx (http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx)

The only thing I wouldn't touch is STATIC_STD_LIBS, neither in SFML nor SFGUI. MSVC doesn't really like it when you static link the runtime.

I haven't experienced any other problems as the ones above but it still isn't such a good idea. ;)
Title: Re: SFGUI
Post by: Nexus on April 05, 2012, 08:59:22 am
Hi, I clicked the thread and saw something on the first page ;)

Using shared_ptr directly is a good solution, unfortunately it appears as such in the docs. Not a big deal, but I'd prefer the consistent "Ptr"/"PtrConst" style.
In Aurora, I've written a macro
#define AURORA_FAKE_DOC(real, fake) real

In doxygen, you define it as fake. With it, you let something else appear in the documentation than in the code. It's also useful for implementation-defined and complicated types of which the details are irrelevant to the user.

I know it's ugly, but I think it's the only solution to have both a clean documentation and no unnecessary header dependencies.
Title: Re: SFGUI
Post by: Tank on April 05, 2012, 09:16:51 am
Meteorhead:
I guess you're doing everything correctly, just one little step you must be aware of: When you build SFGUI with dynamic linkage, the FindSFML script looks for the dynamic libraries and stores them in SFML_*_LIBRARY_DEBUG/RELEASE variables. If you now decide to link against static libraries and check "SFML_STATIC_LIBRARIES", FindSFML won't update those variables.

So when changing SFML_STATIC_LIBRARIES, make sure to delete all SFML_*_LIBRARY_* variables so they're re-initialized. The same goes for FindSFGUI in case you're using it.

The way the whole process works best is to open CMake GUI (if you're using it, otherwise do the equivalent on the CLI) with a fresh and uninitialized environment (e.g. empty 'build' directory), add and set the variables first (that is: SFML_STATIC_LIBRARIES, BUILD_SHARED_LIBS) and then configure & generate.

If you, Laurent, are reading this: I'd suggest to add a variable that tracks the content of SFML_STATIC_LIBRARIES for FindSFML. As soon as it changes the script should automagically delete all SFML_*_LIBRARY_* variables so that they're searched for again. I guess I'll do the same for FindSFGUI. :)
Title: Re: SFGUI
Post by: Tank on April 05, 2012, 09:17:53 am
Ah, forgot to reply to Nexus:
I'm not sure what exactly you're talking about. What does the macro do? (example maybe?)
Title: Re: SFGUI
Post by: Laurent on April 05, 2012, 09:30:32 am
Quote
If you, Laurent, are reading this: I'd suggest to add a variable that tracks the content of SFML_STATIC_LIBRARIES for FindSFML. As soon as it changes the script should automagically delete all SFML_*_LIBRARY_* variables so that they're searched for again. I guess I'll do the same for FindSFGUI.
Ok, just let me know when it's done ;D
Title: Re: SFGUI
Post by: Nexus on April 05, 2012, 02:57:13 pm
When you write
void DoSomething( FAKE_DOC(shared_ptr<Button>, Button::Ptr button) );
the compiler sees the code like
void DoSomething( shared_ptr<Button> button )
and thus doesn't require the definition of Button, while Doxygen generates
void DoSomething( Button::Ptr button )
(if you add the macro also in Doxygen). As mentioned, ugly, but probably the only way ;)

For the specific case of shared_ptr<X> vs. X::Ptr, you could even write a shorter macro:
#define PTR(Type) shared_ptr<Type>

void DoSomething( PTR(Button) );
Title: Re: SFGUI
Post by: Tank on April 05, 2012, 03:00:46 pm
Ah got it now. It's indeed ugly, but can save some includes. Thanks. :)
Title: Re: SFGUI
Post by: player931402 on April 15, 2012, 09:50:24 pm
SFGUI support the lastest version of SFML ? ( Relased today ? )

Sorry for the question but I work with SFML and SFGUI is strongly needed.
Title: Re: SFGUI
Post by: binary1248 on April 15, 2012, 10:15:19 pm
Yeah the RC released today is based of the current master at GitHub which should work the last time I checked. What speaks against downloading SFGUI and trying it out yourself? Either it's you or me who finds out first whether it works or not ;) As always if you find anything you have a feeling is a bug don't mind reporting it, favorably on our forum in other to reduce activity in this one thread.
Title: Re: SFGUI
Post by: Drak on June 12, 2012, 02:19:11 pm
I was skimming through the thread to find an answer, and I checked the docs. But was unable to find what I was looking for.

How do you load a *.theme file? I noticed the entire GUI looks Steam by default  ::)
I don't wish to change the GUI at runtime, but when the program loads.
Title: Re: SFGUI
Post by: eXpl0it3r on June 12, 2012, 03:09:24 pm
You obviously didn't spent that much time in looking for it.
I guess you'll find it in the documentation too, but it's easier just to look at the examples and you would have found this (http://redmine.boxbox.org/projects/sfgui/repository/revisions/master/entry/examples/Test.cpp#L527):
m_desktop.LoadThemeFromFile( "data/example.theme" );
Title: Re: SFGUI
Post by: Rexou on June 12, 2012, 03:35:07 pm
Hi guys,

Quote
How do you load a *.theme file? I noticed the entire GUI looks Steam by default  ::)

After reading the documentation and the samples, i guess it would be something like this :

sfg::Context::Get().GetEngine().LoadThemeFromFile("/path/to/your/file");

Btw, i was wondering, have you got any idea about the release date of the new engine ? BREW is efficient but i had like to customize the differents widgets with images.

You're doing a great and useful job guys, keep it up :)
Title: Re: SFGUI
Post by: binary1248 on June 12, 2012, 05:14:46 pm
Hi guys,

Quote
How do you load a *.theme file? I noticed the entire GUI looks Steam by default  ::)

After reading the documentation and the samples, i guess it would be something like this :

sfg::Context::Get().GetEngine().LoadThemeFromFile("/path/to/your/file");
That would only apply the theme to the context active at that point in time. If you use sfg::Desktop(s) you might have multiple contexts, in which case you would use m_desktop.LoadThemeFromFile( "/path/to/your/file" ); just like in the example eXpl0it3r provided a link to (it isn't really an example, more a test bench).

Btw, i was wondering, have you got any idea about the release date of the new engine ? BREW is efficient but i had like to customize the differents widgets with images.
Bob as it is known is being developed by Iteem. If you want more info or just want to motivate him to work harder you can drop by IRC. With Bob it is possible to theme widgets using images as you have mentioned. Iteem ran into difficulties continuing development after we made the switch to VBO-based rendering. Further he had real-life obligations that prevented him from having much free time right after we made the switch so Bob has been hanging in the air since.

You're doing a great and useful job guys, keep it up :)
Nice to know another person who uses the library. We should have a guestbook-like feature somewhere but Tank is reluctant to make unneeded changes to the website ;).
Title: Re: SFGUI
Post by: Tank on June 14, 2012, 06:50:09 am
Quote
Nice to know another person who uses the library. We should have a guestbook-like feature somewhere but Tank is reluctant to make unneeded changes to the website.
It's generally hard to make me working on any website things, as websites are boring. ;)
Title: Re: SFGUI
Post by: Mars_999 on June 14, 2012, 11:45:15 am
Quote
Nice to know another person who uses the library. We should have a guestbook-like feature somewhere but Tank is reluctant to make unneeded changes to the website.
It's generally hard to make me working on any website things, as websites are boring. ;)

Amen!!!
Title: Re: SFGUI
Post by: The Terminator on July 21, 2012, 03:47:54 pm
Is SFGUI available on Mac? (Xcode)
Title: Re: SFGUI
Post by: binary1248 on July 21, 2012, 03:59:26 pm
It should compile on Mac. We don't use any OS dependent headers and CMake should take care of generating the build configuration.
Title: Re: SFGUI
Post by: The Terminator on July 21, 2012, 05:22:10 pm
I have been trying to use Cmake to compile it with Xcode, but I keep getting these weird errors like "does not appear to have cmakelists". I'm also very confused on where to point the source code part of it to. Help anyone?
Title: Re: SFGUI
Post by: eXpl0it3r on July 21, 2012, 09:07:07 pm
You need to be a bit more specific if you want to have valuable help. Most of use are not developers on a Mac so it's not too easy to understand your problems. ;)

For example you should tell us the exacte CMake error and what do you mean with 'point the source code part'?
Title: Re: SFGUI
Post by: The Terminator on July 21, 2012, 10:20:49 pm
I'm sorry I'm being vague, I'm very new to Cmake and I'm not very familiar with it. What I am talking about, is when I try to build SFGUI on my Mac, I point the source to the main directory of SFGUI, and I point where to build the binaries is a folder that I created inside of it called "build". But, when I try to generate it using Xcode, it gives me an error that says CMake Error: The source directory does not appear to contain CMakeLists.txt. I am very frustrated and I really want to use SFGUI in my adventure game. Any help with this would be IMMENSELY appreciated.
Title: Re: SFGUI
Post by: eXpl0it3r on July 21, 2012, 10:37:19 pm
If you clone the SFGUI repository there should be a CMakeList.txt in the root folder of SFGUI. If you set the source path to the root folder of SFGUI then you should get such an error.

Btw SFGUI has it's own forum, so you maybe better of asking questions there: http://sfgui.sfml-dev.de/forum/ (http://sfgui.sfml-dev.de/forum/)
Title: Re: SFGUI
Post by: The Terminator on July 22, 2012, 01:08:15 am
Thanks for the help, but I've officially given up on SFGUI. I cannot figure out how to include it into my original Xcode project or anything like that. I've tried all day, but I guess I'm stuck with plain old SFML....
Title: Re: SFGUI
Post by: Mars_999 on July 22, 2012, 01:51:29 am
Yeah it would be nice to get SFGUI to an actual release and was drop in a play easy... Someday....
Title: Re: SFGUI
Post by: Hiura on July 22, 2012, 09:49:18 am
Thanks for the help, but I've officially given up on SFGUI. I cannot figure out how to include it into my original Xcode project or anything like that. I've tried all day, but I guess I'm stuck with plain old SFML....
Have you tried to drag and drop the binaries into your project ?

I don't use SFGUI (yet), but I guess you can build it like any other library. (Maybe frameworks build is not available because it's often a pain in the neck to find how to do that with auto-tools. But dylibs build should be available at least.) Now, like any library you need to install it. ... with your bare hands (http://www.sfml-dev.org/tutorials/2.0/start-osx.php) paragraph should give you a hint on the installation process.

Title: Re: SFGUI
Post by: Tank on August 11, 2012, 11:03:11 am
Quote
Yeah it would be nice to get SFGUI to an actual release and was drop in a play easy... Someday....
Some things left before a release can be made:

- Some widgets still missing.
- Waiting for SFML2 to get stable (as in stable *release*), if we decide to keep sticking with it... ;)
- Documentation.

Regarding SFGUI and OSX: We're sorry if it doesn't work properly, but unfortunately we can't test it at all, because nobody of the SFGUI developers owns a Mac. We once received a patch from someone who fixed the CMakeLists.txt to make SFGUI build on OSX, so we assumed that it works.

The Terminator, the best would be to describe what problems you exactly experienced. Even if you're not planning to use SFGUI anymore, it might be of interest for other OSX users.
Title: Re: SFGUI
Post by: Mars_999 on August 11, 2012, 03:56:22 pm
Quote
Yeah it would be nice to get SFGUI to an actual release and was drop in a play easy... Someday....
- Waiting for SFML2 to get stable (as in stable *release*), if we decide to keep sticking with it... ;)


And by that you mean? You will be using something else? Just curious...
Title: Re: SFGUI
Post by: eXpl0it3r on August 11, 2012, 04:42:42 pm
And by that you mean? You will be using something else? Just curious...
SFGUI is already highly depending on OpenGL itself and there are only a 'few' things that keep SFGUI tied to SFML (so I've been told on IRC), so in future they may change those dependecies too and become a GUI library which doesn't depend on any other library directly, but don't worry they won't abandon SFML but rather restructur the rendering engine to be even more modular, so it could be possible to connect the GUI with other graphics libraries. (Although I think the modular renderer could take a bit more time than those 'few' changes, I'm not sure so you should wait for a official statement.) ;)

But with changes ahead a fixed release could again get pushed further back.
Although I don't really see the big advantage of a stable release. Sure for distribution & updates it can be nice to have something that doesn't change anymore and for software security (i.e. that nothing crashes with a new version) it's also good, but I haven't seen a single SFML/SFGUI project that would heavily depend on any of those reasons and personally don't think that there will be on in the new few weeks/month.
The community and popularity has first to grow more, maybe this will happen largly with SFML 2, we'll see. :)
Title: Re: SFGUI
Post by: Mars_999 on August 12, 2012, 05:32:53 pm
Ok, I agree abstract out the input, logic side of the SFGUI lib, but you don't need to abstract out the rendering engine unless you want to have BREW, and allow the user to make their own engine, which IMO just keep using OpenGL as the rendering API as it is the only cross platform API, as your time is limited already and would be a waste to change that.

PLEASE, please finish up the drop down box multi line scroll bar I sent in moths ago as a feature before you head off on that direction I been patiently waiting for it..... :)

Thanks!
Title: Re: SFGUI
Post by: Tank on August 22, 2012, 03:59:56 pm
Infact dropping SFML at least for the rendering part gives us some benefits: We don't have to pay attention at SFML's limitations/ways of doing certain things. The renderer already has nearly nothing in common with SFML's rendering abstraction layer, so it's just logical to drop the dependency completely (as eXpl0it3r said, SFGUI can be used in other OpenGL-powered games/programs too then). However this is not very high on the todo list.

Of course we don't drop the OpenGL dependency -- not sure if you were asking that. ;)

Quote
PLEASE, please finish up the drop down box multi line scroll bar I sent in moths ago as a feature before you head off on that direction I been patiently waiting for it.....
Multiline dropdown box? That doesn't make much sense. I guess you just mean a scrollbar for dropdown box lists that are too large to fit on the screen?
Title: Re: SFGUI
Post by: Mars_999 on August 23, 2012, 02:05:20 am
Infact dropping SFML at least for the rendering part gives us some benefits: We don't have to pay attention at SFML's limitations/ways of doing certain things. The renderer already has nearly nothing in common with SFML's rendering abstraction layer, so it's just logical to drop the dependency completely (as eXpl0it3r said, SFGUI can be used in other OpenGL-powered games/programs too then). However this is not very high on the todo list.

Of course we don't drop the OpenGL dependency -- not sure if you were asking that. ;)

Quote
PLEASE, please finish up the drop down box multi line scroll bar I sent in moths ago as a feature before you head off on that direction I been patiently waiting for it.....
Multiline dropdown box? That doesn't make much sense. I guess you just mean a scrollbar for dropdown box lists that are too large to fit on the screen?

Correct, e.g.is when I have a video mode selection drop downbox, there are  a lot of screensizes to choose from... need to have the ability to scroll.

And yes, my point was DO not drop OpenGL as the rendering API. I would like to see you drop SFML as the drawing API as you could move to GLEW as it should be... :)
Title: Re: SFGUI
Post by: Tank on August 23, 2012, 11:54:05 am
Well, GLEW is only an extension loader library to have access to OpenGL features that either aren't included in core yet or not supported on evil platforms by "design", like on Windows. :)

We are currently using GLee to load extensions, because we've been having issues properly linking both to GLEW and SMFL (I don't remember the details exactly). So yeah, we are already using OpenGL extensions for the renderer.

SFML is mostly used for loading textures, texts, input and utility classes.
Title: Re: SFGUI
Post by: FRex on November 02, 2012, 01:08:09 am
Are there any news about sfg::ListBox ? Last post on your forum I found is from half a year ago.
Or at least
Quote
a scrollbar for dropdown box lists that are too large to fit on the screen
Title: Re: SFGUI
Post by: binary1248 on November 02, 2012, 01:17:34 am
Tank told me he was working on it... a while ago... I don't know what the status on it is right now ;). He'll have to get back to you on that. It seems like he has so many other things to do he hasn't had the time to finish it. We're always looking for new developers, all the time. People seem scared to start contributing even if what they want is easy to implement and they know how to do it themselves. Over the history of the project many people have contributed already, even if they wrote a fix for 1 line of code, it made a difference. As such we would be thankful if there is a submission for a ListBox widget from someone. It seems like a widget many people need ;).
Title: Re: SFGUI
Post by: FRex on November 02, 2012, 01:23:29 am
The notebook is actually way more complex it seems(the ListBox I imagine is vcl style one, just bunch of indices and strings like current combobox) and could do for what I want to do but it's less than ideal.

Also, are shared ptr some sort of special gui ptrs or are they 'just' a shared ptr that can be used as replacement for boost one(I'm avoiding boost atm).

And yes, people are scared because sfgui is written by pros. :)
Title: Re: SFGUI
Post by: binary1248 on November 02, 2012, 01:44:17 am
sfg::SharedPtr was written as a replacement for boost::shared_ptr because we wanted to chop off the dependency and the 20 seconds of extra build time because of it. Don't use SharedPtr if you have another implementation available (use C++11 for this if you can). When I implemented it, I leafed over boost code to get the idea of how it worked and implemented our own without all the stuff SFGUI doesn't need like concurrency support, move support etc.
Title: Re: SFGUI
Post by: FRex on November 02, 2012, 01:46:26 am
I'm avoiding c++11 as well ;D but thanks.
Title: Re: SFGUI
Post by: Tank on November 02, 2012, 08:19:33 am
Quote
Tank told me he was working on it... a while ago... I don't know what the status on it is right now . He'll have to get back to you on that.
I didn't get beyond the planning stage. :( Like binary said, a lot of things are going on at the moment, and I can't dedicate much/any time to SFGUI.

However one thing's for sure: I'll need it too (again) at a point of time in the future. So either someone will have already contributed one or I'll have to do it myself (again). ;) But don't expect this to happen soon.
Title: Re: SFGUI
Post by: FRex on November 02, 2012, 01:18:24 pm
I'm using notebook for that now but it's a bit wasteful, one shared ptr wasted per page, every page has same box as content and I check index and load data from indexed container into widgets in box on tab changes.

Is the notebook bug with adding new pages at runtime fixed in last source?
Title: Re: SFGUI
Post by: FRex on November 02, 2012, 04:51:17 pm
Here's code for bug, new tabs get added on top of first one untill the notebook gets resized, then they fly into their proper places.
//include sfml and sfg
sfg::Notebook::Ptr notebook;
sfg::Button::Ptr adder;
void add()
{
        notebook->AppendPage(adder,sfg::Label::Create("new"));
}
int main(int argc,char * argv[])
{
        sfg::SFGUI gui;
        sf::RenderWindow app(sf::VideoMode(600,600),"notebook bug");
        notebook=sfg::Notebook::Create();
        adder=sfg::Button::Create("add new");
        adder->GetSignal(sfg::Widget::OnLeftClick).Connect(&add);
        notebook->AppendPage(adder,sfg::Label::Create("first"));
        sfg::Desktop desktop;
        sfg::Window::Ptr window=sfg::Window::Create();
        window->Add(notebook);
        desktop.Add(window);
        sf::Clock clock;
        while(app.isOpen())
        {
                sf::Event eve;
                while(app.pollEvent(eve))
                {
                        if(eve.type==sf::Event::Closed) app.close();
                        desktop.HandleEvent(eve);
                }
                desktop.Update(clock.restart().asSeconds());
                app.clear();
                app.resetGLStates();
                gui.Display(app);
                app.display();
        }
}
Title: Re: SFGUI
Post by: Tank on November 02, 2012, 11:45:32 pm
Could you do us a favor and post that bug report to http://redmine.boxbox.org/projects/sfgui/issues? SFML's forum isn't really the right place for it. ;)
Title: Re: SFGUI
Post by: FRex on November 02, 2012, 11:49:33 pm
I have rather old .dlls and .libs of everything so I'm not sure if it reproduces with lastest source.
Title: Re: SFGUI
Post by: Tank on November 03, 2012, 02:07:20 am
Then try downloading the nightly builds from the website. They are only one commit behind.
Title: Re: SFGUI
Post by: FRex on November 03, 2012, 02:12:51 am
No. I'm getting my free vs 2010 pro, have to do it already, and then I'll redownload libs I use, bake the dlls and then try. I'll get back to you about that in around an hour tops. ;)
One does not simply install new compiler and bake his dlls.
Yes, the bug is present with last sources. I added ticket to issues : http://redmine.boxbox.org/issues/538
Title: Re: SFGUI
Post by: firefly2442 on November 04, 2012, 04:21:28 am
I'm getting the following error when adding the necessary include file in my project:

Code: [Select]
fatal error: SFGUI/SFGUI.hpp: No such file or directory
The relevant section in my CMake file for SFGUI is:

Code: [Select]
find_package(SFGUI REQUIRED)
if(SFGUI_FOUND)
  include_directories(${SFGUI_INCLUDE_DIR})
  target_link_libraries(${EXECUTABLE_NAME} ${SFGUI_LIBRARY})
endif()

I was under the impression that the include_directories adds these directories so that the generated solution can identify directories to search in order to find the necessary includes.  I'm guessing it's something simple but... any ideas?

Thanks. :)
Title: Re: SFGUI
Post by: firefly2442 on November 04, 2012, 06:55:19 pm
Fixed it.  There's a bug in FindSFGUI.cmake.  The variable SFGUI_FOUND is set to false at the beginning but never toggled to true.  I posted a bug in the tracker.
Title: Re: SFGUI
Post by: FRex on November 05, 2012, 11:07:24 pm
Is it normal for program to crash when closed using console? I thought it's default deja vu font acting like sfml's old default font but after removing it, I still get crash on exit.
Title: Re: SFGUI
Post by: binary1248 on November 06, 2012, 12:26:43 am
Is it normal for program to crash when closed using console? I thought it's default deja vu font acting like sfml's old default font but after removing it, I still get crash on exit.

You have to elaborate more on this. How does this program function? What do you mean by "closed using console"? What does "crash" mean?

We designed the built-in font to not cause the same problems as the SFML one, that was the whole idea after all. As such it is unlikely that it is the cause for your problem.
Title: Re: SFGUI
Post by: FRex on November 06, 2012, 12:41:24 am
by closing using console i mean pressing the X on the console window when project is compiled as console application
int main()
{
sfg::SFGUI eh;
std::cin.get();//press console window X to crash or enter to quit alright
}
Quote
I thought it's default deja vu font acting like sfml's old default font but after removing it, I still get crash on exit.
removing it = I recompiled without default font so it was not it but since error is like with default font I thought your is same
crash means a very exciting msvc 2010 window saying:
Quote
Unhandled exception at 0x08e9a4cc in EddysTestbed10.exe: 0xC0000005: Access violation reading location 0x000007f0.
and error pointing to disassembly(exactly what default font did in sfml)
I also got(in my older project) similar errro by a bad singleton pattern, using pointer there solved it, so i dug into your code but you are using a pointer for the singleton already.. maybe because it's a smart ptr there is a problem, or maybe im doing something wrong

But since:
Quote
Closing the console is not a clean way to end a program. Closing a program by an external source is never clean, only controlled termination within the program itself is clean.
I'm not sure if it's not meant to happen which is not a big dealreally, just change settings so that console doesn't show up since it's for debugging purposes only anyway(could also redirect the cout and cerr somewhere reasonable).
Title: Re: SFGUI
Post by: binary1248 on November 06, 2012, 01:02:12 am
by closing using console i mean pressing the X on the console window when project is compiled as console application
This is the problem. Many people don't realize that closing the console a graphical application is running in kills the application and doesn't let it do proper cleanup. The only true way to close an SFML application that makes use of sfml-window and sfml-graphics would be to let program execution terminate by itself. Because of RAII this makes sure everything also gets cleaned up properly. When not debugging, you shouldn't have to display the console either. It is only an aid for debugging that you use purely as a place for stdout and stderr to go to, nothing else.

As such this is not a bug, but just wrong usage.
Title: Re: SFGUI
Post by: FRex on November 06, 2012, 01:22:16 am
Yes, I know, just asking because it never caused errors like that except for def font.
Title: Re: SFGUI
Post by: FRex on December 25, 2012, 02:19:31 pm
It seems that trying to go to http://sfgui.sfml-dev.de/download on http://sfgui.sfml-dev.de results in 500, someone confirmed that for me, and it fails on firefox and chrome on windows and firefox on fedora so it's not just my setup that suddenly broke.
Title: Re: SFGUI
Post by: eXpl0it3r on December 25, 2012, 02:27:44 pm
It seems that trying to go to http://sfgui.sfml-dev.de/download on http://sfgui.sfml-dev.de results in 500, someone confirmed that for me, and it fails on firefox and chrome on windows and firefox on fedora so it's not just my setup that suddenly broke.
Yep there seems to be a problem (again). ;)
But the git repository is still up and running: git://boxbox.org/SFGUI.git
Title: Re: SFGUI
Post by: FRex on December 25, 2012, 02:39:19 pm
Isn't that the bleeding edge version?
Title: Re: SFGUI
Post by: eXpl0it3r on December 25, 2012, 03:01:51 pm
Isn't that the bleeding edge version?
That's just the official git repository of SFGUI (same as the one on GitHub for SFML).
If by 'bleeding edge version'  you mean the experimental one, then you're also right, because it's just another branch with the same url, mainly the experimental branch.
If you're referring to the Nightly Builds, then I can't help you further, since I don't know the URLs to them. But they would be anyways outdated, since SFGUI in the middle of moving to a different CI (contiguous integration) tool. ;)
Just compile it on your own and everything should work fine.
Title: Re: SFGUI
Post by: FRex on January 04, 2013, 02:57:57 am
What does IsActiveWidget() return?
I have a box packed with 20 labels, all of which have onleftclick connected to click() method of class that has pointer to box. In click I'm doing a for loop through all pointers in m_Box->GetChildren() and none of them return true for IsActiveWidget.

Strangely, simply packing 20 buttons and not touching any other code works.

A side question, how to make window vertically scrollable?
Title: Re: SFGUI
Post by: Tank on January 04, 2013, 08:08:11 am
Widgets *can* have 4 states: Normal, prelight, selected and active. Not all states are used/supported by all widgets. For example, a label can't get active, it does not make sense. However, when a button gets focus, it's becoming active.

What are you actually trying to do? If you want to get the label that the event was fired for, see sfg::Context::GetActiveWidget() (http://sfgui.sfml-dev.de/doxygen/classsfg_1_1Context.html#a7755cac235ad32affcb1f376a2ec8f16) or use functors.

Quote
A side question, how to make window vertically scrollable?
You can't, but you can put everything inside an sfg::ScrolledWindow and add that to the window.

Edit: Oh and by the way, sorry for the download page problems lately. Jenkins CI is going crazy, crashing almost every 15-20 minutes. The download page script fetches live data from Jenkins for the nightly statuses, even when it's down, and that's why it's failing with 500.

The problem will be solved with an updated website and a first binary release, i.e. nightly builds won't be available for quite some time. Instead, we plan to push out smaller releases more often.
Title: Re: SFGUI
Post by: FRex on January 04, 2013, 11:32:55 am
I was trying to simulate a listbox(that curiosly appears in features list ;D) by having box of labels and all labels connected to same method and then fetching index of label that was actually clicked on. But I was refilling it with new labels every click so labels got invaldated mid-signal which caused weird errors so I must give it up, write own listbox(fat chance) or make weird workarounds(like if box of labels wasn't weird enough).
For download, I guess I'll just git clone SFML and SFGUI whenever I want to recompile, less hassle that way.
Title: Re: SFGUI
Post by: FRex on January 05, 2013, 07:30:08 pm
I don't know if it's relevant but the type of blending used in last SFML draw call is affecting the SFGUI::Display just after it, often in bad ways that look like bugs but probably aren't.
Title: Re: SFGUI
Post by: trilavia on January 06, 2013, 07:34:49 pm
The download on http://sfgui.sfml-dev.de/download gives error 500 and the github project from the first post doesn't exist. How can I download sfgui?
Title: Re: SFGUI
Post by: FRex on January 06, 2013, 07:40:14 pm
One does not simply download the best gui for sfml.
Do: git clone git://boxbox.org/SFGUI.git
You should have git bash shortcut on desktop after downloading and installing git for windows.
Title: Re: SFGUI
Post by: trilavia on January 06, 2013, 07:52:32 pm
I use linux actually :P
Is there a way to theme sfgui in some way (images, css layouts, whatever)? As the default font and theme isn't good for me.
Title: Re: SFGUI
Post by: FRex on January 06, 2013, 07:57:12 pm
Then terminal work is no problem for you.
There is some way and there are examples with example theme file in /examples.
I didn't dig into it  yet, I like old steam look.
Title: AW: SFGUI
Post by: eXpl0it3r on January 06, 2013, 08:19:04 pm
Yes you can define everything in code or load an external file. I think both ways are shown in the examples. To get an understanding of the capability of the styles, you can look at the BREW headee that sets all the defaults.
Title: Re: SFGUI
Post by: Tank on January 07, 2013, 11:06:14 am
Images for the widgets themselves, i.e. the theme, are not possible at the moment. Iteem is working on a bitmap renderer.
Title: Re: SFGUI
Post by: FRex on January 07, 2013, 11:59:18 pm
Quote
use functors.
How to use functors with connect?
Can things returned by std::bind be used?
Title: Re: SFGUI
Post by: Gan on January 08, 2013, 09:44:08 am
This looks amazing. I was thinking of using GUIchan for my game but this certainly seems much better due to the fact that it's SFML native!

But now I just found TGUI, and I'm stricken. I don't know which to use....
Title: Re: SFGUI
Post by: Tank on January 08, 2013, 06:29:39 pm
Quote
How to use functors with connect?
Everything that's convertible to void(void) can be used, e.g. "struct Functor { void operator()() { ... }; };
Title: Re: SFGUI (0.0.0 released)
Post by: Tank on January 08, 2013, 06:38:45 pm
We released version 0.0.0, a preview release. Have fun! (http://sfgui.sfml-dev.de/download)
Title: Re: SFGUI (0.0.0 released)
Post by: FRex on January 08, 2013, 06:48:04 pm
Finally.. Documentation.. *drolls*..
Still, I'm missing something substantial with functors:
buttons->GetSignal(sfg::Widget::OnLeftClick).Connect(Functor);//nope
buttons->GetSignal(sfg::Widget::OnLeftClick).Connect(fun);//instance of class Functor, nope
buttons->GetSignal(sfg::Widget::OnLeftClick).Connect(&fun);//nope
 
Title: Re: SFGUI (0.0.0 released)
Post by: Tank on January 08, 2013, 07:12:54 pm
See the examples/Signals.cpp file for an example, class "BazClass". If you're missing other ways, feel free to add a ticket at the tracker (http://redmine.boxbox.org/projects/sfgui).
Title: Re: SFGUI (0.0.0 released)
Post by: iride on January 09, 2013, 01:28:54 am
Hi, I'm having some trouble learning the API with the documentation alone. Where can I get some additional example code other than Hello, World!?
Title: Re: SFGUI (0.0.0 released)
Post by: eXpl0it3r on January 09, 2013, 01:35:28 am
Where can I get some additional example code other than Hello, World!?
Just open your eyes! :)

There's a whole examples directory included with the binaries and the source; you can also view them online here (http://redmine.boxbox.org/projects/sfgui/repository/revisions/master/show/examples).
Title: Re: SFGUI (0.0.0 released)
Post by: iride on January 09, 2013, 02:15:44 am
ops, must have been blind
Title: Re: SFGUI (0.0.0 released)
Post by: eigenbom on January 09, 2013, 04:56:19 am
We released version 0.0.0, a preview release. Have fun! (http://sfgui.sfml-dev.de/download)

Congrats, runs great. :)
Title: Re: SFGUI (0.0.0 released)
Post by: Tank on January 09, 2013, 02:17:11 pm
Thanks. ;)

By the way, we're preparing the release of version 0.0.1, which is compatible with the latest SFML revision again (one(!) line in SFGUI used a_texture.bind() ::)).
Title: Re: SFGUI (0.0.0 released)
Post by: Laurent on January 09, 2013, 02:22:50 pm
Quote
one(!) line in SFGUI used a_texture.bind()
*evil laugh* ha ha ha ha!

Although I say that the 2.0 API is frozen, I try to always find last minute modifications, just to break users code. This one worked beautifully ;D
Title: Re: SFGUI (0.0.0 released)
Post by: Tank on January 10, 2013, 08:49:41 am
You're truly a kind person, Mr. Laurent. ;-)
Title: Re: SFGUI (0.0.1 released)
Post by: Tank on January 10, 2013, 04:09:01 pm
0.0.1 is now available.
Title: Re: SFGUI (0.0.1 released)
Post by: FRex on January 17, 2013, 02:42:31 pm
I'm not sure but it seems like you're doing your RestoreGL that memsets cache in target to 0 after binding your atlas. That means that vertices that have texture coords set will not draw properly when not using any texture without doing something about your atlas.
#include <SFML/Graphics.hpp>
#include <SFGUI/SFGUI.hpp>
int main()
{
        sf::RenderWindow app(sf::VideoMode(600,600),"bug");
        app.resetGLStates();
        sfg::SFGUI gui;
        sfg::Desktop desk;
        desk.Add(sfg::Window::Create());
        sf::Event eve;
        sf::Clock clo;
        sf::Vertex ver[4];
        ver[1].texCoords=ver[1].position=sf::Vector2f(0.f,256.f);
        ver[2].texCoords=ver[2].position=sf::Vector2f(256.f,256.f);
        ver[3].texCoords=ver[3].position=sf::Vector2f(256.f,0.f);
        for(int i=0;i<4;++i)
        {
                //ver[i].texCoords=sf::Vector2f();//doing that fixes it as well, but that's not the point
        }
        while(1)
        {
                while(app.pollEvent(eve))
                {
                        desk.HandleEvent(eve);
                        if(eve.type==sf::Event::Closed) return 0;
                }
                desk.Update(clo.restart().asSeconds());
                app.clear();
                gui.Display(app);
                if(sf::Keyboard::isKeyPressed(sf::Keyboard::Space))
                {
                        sf::Texture::bind(nullptr);
                }
                app.draw(ver,4,sf::Quads);
                app.display();
        }
}
The effect this code gives me(I really hope it's not just me) is that I get nothing except sfg window inside sf window drawn unless I press space or uncomment the zeroing of texture coords from the array.
Here's ready to test .exe of that from vs 10: https://docs.google.com/file/d/0B8dEkQw1a4WveFdDTWpWQ2ljYWc/edit
Title: Re: SFGUI (0.0.1 released)
Post by: binary1248 on January 18, 2013, 02:23:30 pm
...
Fixed.
Title: Re: SFGUI (0.0.1 released)
Post by: Tank on February 12, 2013, 04:50:31 pm
0.1.0 released, here's the changelog (http://redmine.boxbox.org/projects/sfgui/repository/entry/CHANGELOG), here's the download (http://sfgui.sfml-dev.de/download/).

Thanks to eXpl0it3r for building the Windows builds.
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on February 12, 2013, 10:25:42 pm
We're currently planning to change SFGUI's codebase to support some C++11 features available in modern compilers. Before doing that, we'd like to know if the majority of people actually use C++11-enabled compilers.

We'd be very happy if you could spend 1 minute on answering this very short survey: http://goo.gl/I04Yz

Thanks in advance.
Title: Re: SFGUI (0.1.0 released)
Post by: Laurent on February 12, 2013, 10:51:19 pm
I don't think that there's any good reason to stay stuck with a C++03 compiler: all free compilers on all OSes now have a version that supports C++11.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 12, 2013, 10:54:58 pm
Helpful table, I don't know how accurate:
http://wiki.apache.org/stdcxx/C++0xCompilerSupport
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on February 12, 2013, 11:08:59 pm
Laurent:
Yes, and personally I had used C++0x even years ago if a compiler which name I won't tell would care about adopting new standards on time and with some more care. ;-)
To get serious: we are just interested how the current situation looks like and what features can be safely used without making a lot of people unhappy. We all know that the update policy of VC++ users is different from those using "standalone" compilers due to the IDE, which new GUI might not please everyone in the first months after release.

The change to C++11 will come, that's for sure. The question is which features are possible now without breaking builds for the majority of users. Once we use lambdas, we can't look back. ;)

FRex:
The table is good, but it lacks info about stdlib support.
Title: Re: SFGUI (0.1.0 released)
Post by: Gan on February 14, 2013, 09:50:56 pm
I can't seem to be able to download the source for 0.1. The file is seemingly missing.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 14, 2013, 10:19:38 pm
You can do
git clone git://boxbox.org/SFGUI.git
In case you don't have git and can't wait to grab sfgui here's 7z archive:
https://legacy.sfmluploads.org/file/170/download

Hope Tank and Exploiter don't mind.. :P
Title: Re: SFGUI (0.1.0 released)
Post by: eXpl0it3r on February 14, 2013, 10:36:09 pm
I can't seem to be able to download the source for 0.1. The file is seemingly missing.
Sorry for the inconvenience, it seems there has been either a server problem or someone deleted the files by accident. I've uploaded all missing parts again.

In case you don't have git and can't wait to grab sfgui here's 7z archive:
Hope Tank and Exploiter don't mind.. :P
Thanks for jumping in real quick. ;)
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 14, 2013, 10:41:20 pm
Quote
Thanks for jumping in real quick. ;)
Do I seem very much like a wannabe helper? :(
Title: Re: SFGUI (0.1.0 released)
Post by: eXpl0it3r on February 14, 2013, 10:59:38 pm
Do I seem very much like a wannabe helper? :(
No? ???
If my sentence or actions somehow offended you, then I'm sorry. I simply wanted to thank you for your work. :)
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 14, 2013, 11:01:01 pm
Okay, cool. :)
It took me no time at all, it's no big deal.

I repeat:
Quote
You can do
git clone git://boxbox.org/SFGUI.git
In case you don't have git and can't wait to grab sfgui here's 7z archive:
https://legacy.sfmluploads.org/file/170/download

Tank, did you consider allowing connection to a function that takes a sfg::Callback?
Where sfg::Callback would be a class holding const reference to triggering event and const pointer to sender wigdet? That'd be very convenient for some things.
Like now, I have to send enter to my class which checks if our entry is selected and if yes, then sends text. I can't connect signal for that.
Or something similar, it's workable around, it's not a big deal, just convenience.
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on February 15, 2013, 08:42:11 am
I really have no clue what happened with the files. Needs some investigation I guess.

Quote
Tank, did you consider allowing connection to a function that takes a sfg::Callback?
We're currently playing around with std::function for signal handlers together with a new function signature for the callbacks.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 22, 2013, 07:45:47 pm
Is there some technical reason for not including extlibs/sfml/lib/ sfml-system-d.lib and sfml-system.lib in precompiled vs10 x86 pack while including dlls or is this a mistake?
Title: AW: SFGUI (0.1.0 released)
Post by: eXpl0it3r on February 22, 2013, 09:01:33 pm
This seems like a mistake, but since my notebook got stolen today, I won't be able to fix it that quickly...
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 22, 2013, 09:17:24 pm
Stolen notebook, so so sad :( (I'm not being sarcastic)

Edit: Is there any consideration for in-sfgui support for checking if event gets consumed?
Irrlicht's event using classes return bool that tells if they used up the event or if it's still unhandled.
So anything that produces result(valid clicks, text and backspaces that do reach some inputable widget) and clicks that land on sfgui area(usually gui is on top and blocks input to everything below) could return false/true.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 24, 2013, 03:19:13 pm
There's a small error in the online doc:
http://sfgui.sfml-dev.de/doxygen/classsfg_1_1Widget.html#aa0f8275f53a6157112108c0944d30f54
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on February 26, 2013, 08:44:15 am
The event handling is still one of those things I want to change massively in the future. First off to decouple SFGUI more from SFML and second off to make things like you requested possible. I'm currently investigating if the way it's done in the browser (the event bubbling thing) might be interesting.

Thanks for pointing out the docs issue. It would be very nice if you could create a ticket (http://redmine.boxbox.org/projects/sfgui/issues) for that, so it won't be forgotten.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on February 26, 2013, 06:35:22 pm
http://redmine.boxbox.org/issues/594
With these bugs I find and features I miss I feel like I'm either whining non stop(I'm not, SFG's great) or being the sole user of SFG(I hope not, SFG's great). :-\ ;D
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on February 26, 2013, 10:29:23 pm
http://redmine.boxbox.org/issues/594
With these bugs I find and features I miss I feel like I'm either whining non stop(I'm not, SFG's great) or being the sole user of SFG(I hope not, SFG's great). :-\ ;D
Not really, it always depends on how people use SFGUI. If you are content with a Window, Box, a few Labels and Buttons then you probably won't find anything because we adopt an incremental/iterative development work flow and those widgets have been around for like... only Tank knows. As such probably all bugs specific to those widgets were already fixed long ago. Bugs affecting all widgets because they are introduced by architecture changes are something else though and we try to test those changes thoroughly before "releasing" them. Nonetheless despite thorough testing a few might get through and we are grateful for every report.

And as for missing features, as I said, we work incrementally. Hopefully there will be a day where all features requested by everyone will be implemented. The order in which they get implemented and IF they get implemented depends on the users, the more they whine, the higher priority it gets ;). Features that are too specific and can be constructed to a certain degree from pre-existing things will probably not get implemented, but I assume this is the case with every library out there so everybody should already know this.
Title: Re: SFGUI (0.1.0 released)
Post by: JayArby on February 27, 2013, 11:53:00 pm
The SFGUI downloads on the website say that they include compatible sfml libs.

However, the "sfml-system.lib" library is not included. I am getting linker errors without it. Am I missing something?

I'm going to try compiling with eXpl0it3r's build of sfml-system.lib, but I'm pretty sure it's incompatible with SFGUI's libs.

EDIT:
I compiled with eXpl0it3r's unofficial nightly build of sfml-system.lib and it seems to work fine. I'm sure this is not a good idea, however, because I know that there is some incompatibility between them (I tried linking sfgui applications against eXpl0it3r's libs before and had dll errors).

FYI the sfgui package I downloaded was for vs2012
Title: AW: SFGUI (0.1.0 released)
Post by: eXpl0it3r on February 28, 2013, 12:34:30 am
They are perfectly compatible, since they are the same. :D
Not sure what DLL errors you're talking about...
I'm kind of SFGUI's CI (continous integration) for Windows.

The missings libs are my mistake, but as stated before, it will take a while, till my system is back again (should get a new notebook as replacement for the stolen one today).
Until then it's safe to use the nightly builds. ;)
Title: Re: SFGUI (0.1.0 released)
Post by: Cpl.Bator on March 13, 2013, 02:14:28 am
how can i see the shadow in the window ?
i try to play with this :
Quote
SetProperty( "Window", "ShadowDistance", 100.f );
   SetProperty( "Window", "ShadowAlpha", 255.f );
but, no visual change.
i've included sfgui directly in my test project.
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on March 13, 2013, 02:19:00 am
You need to specify the sfg::Window::SHADOW style on the Window either when you create it or after that with SetStyle(...). It is not enabled by default. See http://sfgui.sfml-dev.de/doxygen/classsfg_1_1Window.html for more.
Title: Re: SFGUI (0.1.0 released)
Post by: Cpl.Bator on March 13, 2013, 09:07:39 pm
Thx ;)
Title: Re: SFGUI (0.1.0 released)
Post by: kralo9 on March 19, 2013, 07:02:06 pm
I got a problem: If i try to change my gui by calling desktop.RemoveAll() and then adding the new widgets to the desktop I can still see the old widgets :/
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 19, 2013, 07:03:43 pm
Are you doing desktop.Update(someclock.restart().asSeconds())? If not, maybe try it..
Title: Re: SFGUI (0.1.0 released)
Post by: kralo9 on March 19, 2013, 07:08:02 pm
Are you doing desktop.Update(someclock.restart().asSeconds())? If not, maybe try it..

I do. But it can be that I update not immediatly after removing and I already add the new gui. Should I update immediatly?

Edit: Just tried to update immediatly. Didn't solve the problem.
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on March 19, 2013, 07:38:31 pm
You need to destroy the old widgets. While they still exist (because you still own them) they will be rendered. If you don't intend on using them any more in the future, just let them go out of scope or explicitly call .reset() on each of their Ptrs. If you do intend on using them again in the future, do not remove them from the desktop to stop them from being displayed, simply hide them instead.
Title: Re: SFGUI (0.1.0 released)
Post by: kralo9 on March 19, 2013, 07:43:42 pm
You need to destroy the old widgets. While they still exist (because you still own them) they will be rendered. If you don't intend on using them any more in the future, just let them go out of scope or explicitly call .reset() on each of their Ptrs. If you do intend on using them again in the future, do not remove them from the desktop to stop them from being displayed, simply hide them instead.

Thanks. If I hide the sfg::Window I can use it later :) but I hope the widgets aren't interactive when hided, are they?

Edit: Additionally: How did you mask the password entry in the text.exe?
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 19, 2013, 07:55:34 pm
void sfg::Entry::HideText ( sf::Uint32  c)
I think..
Title: Re: SFGUI (0.1.0 released)
Post by: kralo9 on March 19, 2013, 08:19:24 pm
void sfg::Entry::HideText ( sf::Uint32  c)
I think..

Ah obvious function detected :D Yes thanks.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 25, 2013, 12:40:41 am
#include <SFML/Graphics.hpp>
#include <SFGUI/SFGUI.hpp>
int main()
{
        sf::RenderWindow app(sf::VideoMode(600,480),"Heh");
        app.setFramerateLimit(30);
        sfg::SFGUI sfgui;
        sfg::Desktop desk;
        sf::Event eve;
        sf::Clock clo;

        sfg::Window::Ptr win=sfg::Window::Create();
        sfg::ScrolledWindow::Ptr scr=sfg::ScrolledWindow::Create();
        scr->SetRequisition(sf::Vector2f(150.f,150.f));
        win->Add(scr);
        sfg::Box::Ptr box2=sfg::Box::Create();
        scr->AddWithViewport(box2);

        for(int i=0;i<10;++i)
        {
                box2->Pack(sfg::Label::Create("Hello World"));
        }
        desk.Add(win);
        app.resetGLStates();
        while(app.isOpen())
        {
                app.clear();
                while(app.pollEvent(eve))
                {
                        if(eve.type==sf::Event::Closed) app.close();
                        desk.HandleEvent(eve);
                }
                desk.Update(clo.restart().asSeconds());
                sfgui.Display(app);
                app.display();
        }
}
Is this wrong usage? If not, this causes a bug where scrolled window scrolls appear as 1 pixel thin lines untill window is resized, clicked, etc. Could someone confirm this?

[attachment deleted by admin]
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 25, 2013, 06:27:48 pm
Please report it as a bug at our tracker (http://redmine.boxbox.org/projects/sfgui). binary1248 will be quite happy to hear from another ScrolledWindow bug. ;)
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 25, 2013, 06:36:10 pm
That went well..., I thought that selecting my code and clicking 'inline code' will mark it as 'source code' and display it in a box or something, spoiler: it didn't:
http://redmine.boxbox.org/issues/603
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on March 25, 2013, 07:31:26 pm
You could have saved yourself the trouble. I already looked into it last night right after you posted. The fix was already done this afternoon. Tank always rushes people to add stuff to the tracker. He thinks he can put me under pressure that way, and yet he still hasn't merged in the last several commits I made ::).
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 26, 2013, 01:29:48 am
No, I ask people to add stuff to the tracker so they won't be forgotten and they are at one place, instead of having to look through forum threads. Pressure? This is volunteer work, that's wouldn't be very fair. ;) Nice that a fix is already there. I really try to merge tomorrow and prepare a bug fix release. Thank you.
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 26, 2013, 09:57:17 am
Merged in 0.2.0 branch (http://redmine.boxbox.org/projects/sfgui/repository?rev=0.2.0). I think we gonna release a bugfix release prior to 0.2.0. I have to talk to eXpl0it3r, the build master. :P
Title: Re: SFGUI (0.1.0 released)
Post by: kamui on March 26, 2013, 09:33:08 pm
Hello,

I started using your library, and all works great, but I didn't find how to align my boxes to the center of my sfml window. I saw some threads where binary1234 gave explanations on using sfg::alignment, but it has no effect on my code.

Here's an example of what I tried :

sfg::Box::Ptr box = sfg::Box::Create( sfg::Box::VERTICAL );
sfg::Alignment::Ptr center = sfg::Alignment::Create();
center->SetAlignment(sf::Vector2f(1366.f, 768.f));
box->Pack(center, true, true);
 

Did I do something wrong ?
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 26, 2013, 11:08:41 pm
What stage is std::bind integration at? Because I just took few minutes and added it in, I edited Signal.hpp and Signal.inl, all the other code is the same, I had to typedef sfg::Delegate to std::function<void(void)> and do something in the body of your Connect overload for method so your internal widgets code would work.
Examples seem to work still..
This code now work:
#include <SFML/Graphics.hpp>
#include <SFGUI/SFGUI.hpp>
#include <iostream>
void testfunction1(const std::string& str,char chr)
{
        std::cout<<str<<chr<<std::endl;
}
void testfunction2()
{
        std::cout<<"WHY!?"<<std::endl;
}
class testclass
{
public:
        void testmethod()
        {
                std::cout<<"P.S. sfg::ListBox and YAML are missing still too"<<std::endl;
        }
};
int main()
{
        sfg::SFGUI sfgui;
        sfg::Desktop desk;
        sfg::Window::Ptr win=sfg::Window::Create();
        desk.Add(win);
        sfg::Box::Ptr box=sfg::Box::Create(sfg::Box::VERTICAL,1.f);
        sfg::Button::Ptr button=sfg::Button::Create("TestBound");
        button->GetSignal(sfg::Button::OnLeftClick).Connect(std::bind(testfunction1,"Stefan why no std::bind :(",'?'));
        box->Pack(button);
        button=sfg::Button::Create("TestFree");
        button->GetSignal(sfg::Button::OnLeftClick).Connect(testfunction2);
        box->Pack(button);
        button=sfg::Button::Create("TestMember");
        testclass obj;
        button->GetSignal(sfg::Button::OnLeftClick).Connect(&testclass::testmethod,&obj);
        box->Pack(button);
        win->Add(box);
        sf::RenderWindow app(sf::VideoMode(600,480),"std::bind is (not) a lie");
        app.resetGLStates();
        app.setFramerateLimit(30);
        sf::Clock clo;
        sf::Event eve;
        while(app.isOpen())
        {
                while(app.pollEvent(eve))
                {
                        if(eve.type==sf::Event::Closed) app.close();
                        desk.HandleEvent(eve);
                }
                desk.Update(clo.restart().asSeconds());
                app.clear();
                sfgui.Display(app);
                app.display();
        }
}
Of course my trick is quite stupid (could also get it to pass the instigator widget to bound function after some deeper work, that'd be even nicer that plain std::bind) and not tested at all but it seems to work, if anyone is willing to test/risk using that stuff I added it in attachment.
Also, if c++11 is going to happen, will you remove sfg::SharedPtr?
And I've added '//FREX' comment to every line I edited or added so you can grep for them if you want to see what I did.
Sorry if I sound patronizing or whiny.

[attachment deleted by admin]
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on March 27, 2013, 02:35:02 am
Hello,

I started using your library, and all works great, but I didn't find how to align my boxes to the center of my sfml window. I saw some threads where binary1234 gave explanations on using sfg::alignment, but it has no effect on my code.

Here's an example of what I tried :

sfg::Box::Ptr box = sfg::Box::Create( sfg::Box::VERTICAL );
sfg::Alignment::Ptr center = sfg::Alignment::Create();
center->SetAlignment(sf::Vector2f(1366.f, 768.f));
box->Pack(center, true, true);
 

Did I do something wrong ?
Look at Layout.cpp in the examples folder.
Title: Re: SFGUI (0.1.0 released)
Post by: eXpl0it3r on March 27, 2013, 08:37:20 am
I think we gonna release a bugfix release prior to 0.2.0. I have to talk to eXpl0it3r, the build master. :P
Oh no! I'm not here, never have, never will be! ;D

Na, I'll just have to recreate the build scripts for SFGUI as well, but I'm already behind with Thor. :o
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 27, 2013, 11:09:21 am
FRex:
It's almost finished. I'm not just replacing the fast delegates by std::function, but also change the whole signalling concept internally. Besides of that, we're also dropping sfg::SharedPtr in favor of std::shared_ptr.

After the changes there will be only one function that can be used to register a signal callback. It expects a function<void( uint32_t, shared_ptr<sfg::Object> )>, where the first parameter is the signal ID and the second the emitter object (or widget).

To make it more comfortable to work with, I'm writing sfg::SignalRouter, which you can use to register signals per widget like this:

sfg::SignalRouter router;
router.AddHandler( my_widget, sfg::Button::OnLeftClick, []( shared_ptr<sfg::Button> button ) { // Do something } );

The router will then dispatch signals whenever it receives them from the proper object. The third parameter, by the way, is a std::function.

Also, for a future version (maybe for 0.3.0 or 0.4.0, it's really not decided yet), it's planned to decouple the widgets completely from rendering. At the moment they are calling the active rendering engine to get visuals, which makes them dependent on the engine.

So basically at least the signalling/shared_ptr stuff is what's taking so long -- besides me not having as much free time as I'd love to have. ;)

Quote
Na, I'll just have to recreate the build scripts for SFGUI as well, but I'm already behind with Thor.
SFGUI is more important!!1! ;)
Title: Re: SFGUI (0.1.0 released)
Post by: kamui on March 27, 2013, 01:14:45 pm
Hello,

I started using your library, and all works great, but I didn't find how to align my boxes to the center of my sfml window. I saw some threads where binary1234 gave explanations on using sfg::alignment, but it has no effect on my code.

Here's an example of what I tried :

sfg::Box::Ptr box = sfg::Box::Create( sfg::Box::VERTICAL );
sfg::Alignment::Ptr center = sfg::Alignment::Create();
center->SetAlignment(sf::Vector2f(1366.f, 768.f));
box->Pack(center, true, true);
 

Did I do something wrong ?
Look at Layout.cpp in the examples folder.

thanks.
Title: Re: SFGUI (0.1.0 released)
Post by: AlexxanderX on March 27, 2013, 01:57:38 pm
I need some help please: http://sfgui.sfml-dev.de/forum/topic204-installing-problem.html (http://sfgui.sfml-dev.de/forum/topic204-installing-problem.html)
Title: Re: SFGUI (0.1.0 released)
Post by: eXpl0it3r on March 27, 2013, 02:00:24 pm
I need some help please: http://sfgui.sfml-dev.de/forum/topic204-installing-problem.html (http://sfgui.sfml-dev.de/forum/topic204-installing-problem.html)
There's no need to cross post/link.
binary and Tank are regularly checking the forum, just be patient. ;)
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 27, 2013, 02:37:03 pm
Is there a line saying 'by not providing FindSFML.cmake  in _some variable name_ (...)'?
If yes then adding and setting that variable(I think it was CMAKE_MODULE_PATH) to D:\Libs\cmake\Modules(your path will be different of course) and setting its' type to path should fix that.

Build with cmake is fun. ;)
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 27, 2013, 02:37:27 pm
Well, we might talk about paid support, if you like. :P
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 27, 2013, 02:38:11 pm
Quote
Is there a line saying 'by not providing FindSFML.cmake  in _some variable name_ (...)'?
No, FindSFML.cmake can't find the SFML libs, so SFML_ROOT needs to be added.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 27, 2013, 02:42:04 pm
Quote
No, FindSFML.cmake can't find the SFML libs, so SFML_ROOT needs to be added.
And twist your tongue just right and then... maybe it'll build. ;)
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 30, 2013, 12:18:56 am
I forgot to ask again: will HandleEvent return bool?(I've seen some void function labeled as returning bool in docs so I guess you're moving towards that..) and will signals send const & to triggering event so it's possible to work with that to do things like 'send string somewhere and then clear the entry content' if it was the enter key that was pressed?
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on March 30, 2013, 02:24:08 am
No, HandleEvent will not return bool. We probably forgot to remove some obsolete stuff from the Doxygen comments.

In case you're asking if we'll give the underlying sf::Event to the signal handler: No, that won't happen. Since you're the one giving it to SFGUI's event handler, you should be able to check for the key that was pressed.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on March 30, 2013, 02:40:38 am
Ok, thanks. :D
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on April 13, 2013, 11:01:45 pm
int main(int argc,char * argv[])
{
        sf::RenderWindow app(sf::VideoMode(600,480),"heh");
        sfg::SFGUI sfg;
        sf::Event eve;
        sf::Clock clo;
        sfg::Desktop desk;
        sfg::Window::Ptr win=sfg::Window::Create();
        sfg::Scale::Ptr scale=sfg::Scale::Create(0.f,10.f,1.f);

        win->Add(scale);

        desk.Add(win);

       
        app.resetGLStates();
        while(app.isOpen())
        {
                while(app.pollEvent(eve))
                {
                        desk.HandleEvent(eve);
                }
                desk.Update(clo.getElapsedTime().asSeconds());
                app.clear();
                sfg.Display(app);
                app.display();
        }



}
Holding the scale slider and moving cursor out of the window causes 'failed to share opengl context' error in console and makes the app stuck.

Also, you can't assign sfg::Adjustment::Ptr to sfg::Widget::Ptr.
It says 'error C2440: 'initializing' : cannot convert from 'sfg::Adjustment *const ' to 'sfg::Widget *'
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on April 14, 2013, 03:40:08 am
Holding the scale slider and moving cursor out of the window causes 'failed to share opengl context' error in console and makes the app stuck.
Fixed in testing, seems I forgot a check ;).

Also, you can't assign sfg::Adjustment::Ptr to sfg::Widget::Ptr.
It says 'error C2440: 'initializing' : cannot convert from 'sfg::Adjustment *const ' to 'sfg::Widget *'
sfg::Adjustment is not an sfg::Widget and thus you cannot perform the conversion. They both inherit from sfg::Object. sfg::Adjustment is merely a data structure that holds diverse adjustment information for other widgets.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on April 20, 2013, 11:37:08 pm
Does separator make any sense when attached to table?
Also, I found two custom signals in combo box, one in toggle button, one in entry, is that all of them?
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on April 21, 2013, 12:43:23 am
Does separator make any sense when attached to table?
You can add whatever you want to a table. A separator is nothing but a straight line that is meant to visually separate different sections of the GUI. Rather than loading in a straight line image, we provided a widget just for that :).

Also, I found two custom signals in combo box, one in toggle button, one in entry, is that all of them?
Adjustment, ComboBox, Entry, SpinButton, ToggleButton and Widget all declare their own signals.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on April 21, 2013, 12:45:36 am
Quote
Widget all declare their own signals
That was redundant to mention...  :P
Thanks for both answers.
sfg::Image attached to table with FILL is slow when resizing window that is hosting the table and I mean really slow.
Expand is completely ok, fill isn't and causes visible fps drop.
Toggle button with image is slow to press too. Basically: image = f**k performance. :-\
Also, will the std::bind introducing update break the old Connect calls very much or are they replaceable easily?
Title: Re: SFGUI (0.1.0 released)
Post by: tedsta on April 24, 2013, 01:24:21 am
I'm definitely experiencing the sfg::Image performance hurt - but hopefully there's a workaround for my problem :P So, I'm trying to have a MiniMap embedded in an sfg::Window. I looked around, and decided to give sfg::Image a shot. So, I have an sfg::Image inside my sfg::Window, and I render the MiniMap onto a sf::RenderTexture, then grab the texture and copy it to an sf::Image, which is then set as the sfg::Image's image. This is painfully slow. Is there a better way?

EDIT: And in the beginning, when I said performance hurt, I'm more referring to sf::Texture::copyToImage being painfully slow, not the sfg::Image lag when you resize the window :P If only there was a way to render directly to an sf::Image....
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on April 24, 2013, 02:00:54 am
The question is: do you really need to draw to a RenderTexture? I assume you draw the minimap based on data that is available to you already in the game state somewhere. Why don't you just draw to an sf::Image directly instead of streaming to the GPU and reading the data back, only to send it back to the GPU again? As long as you manipulate the minimap data in your main memory and transfer once per frame it should stay relatively fast. If you want to do some sort of compositing, this can also be done in RAM. Maybe I underestimate what your minimap looks like ::).

But... if you are brave enough, you can use the super brand new undocumented feature of SFGUI called GLCanvas. It basically gives you a drawing surface encapsulated in a Widget where you can do all sorts of SFML or even raw OpenGL drawing, at 0 overhead. Like I said, it is undocumented (a.k.a there is no example yet :P) but with the help of the doxygen pages and the code in Test.cpp you should figure it out in no time.
Title: Re: SFGUI (0.1.0 released)
Post by: Kojay on April 24, 2013, 09:00:09 pm
Hi, I downloaded the 0.1.0 release for VS2010 and SFML system.lib files seem to be missing - not a huge issue but detracts from the convenience of the package a bit.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on April 24, 2013, 09:06:34 pm
Exploiters fault:
http://en.sfml-dev.org/forums/index.php?topic=6112.msg73876#msg73876
 ;D :P
Title: Re: SFGUI (0.1.0 released)
Post by: Kojay on April 24, 2013, 11:04:15 pm
Ah my bad. Anyhow, I wanted to try GLCanvas to draw with SFML on it but I must admit I 'm not sure how (test.cpp uses GL commands to draw on it). Is it possible to use it in similar fashion to an sf::RenderTarget?
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on April 25, 2013, 01:29:13 am
You can do everything with GLCanvas that you would do in a "normal" SFML application. Just pretend you have a normal sf::RenderWindow that is confined within the space of that widget. If you want to draw something with SFML you can do it normally. Note however that you will have to define a custom sf::View or OpenGL Viewport if you want things to be the same size as in the normal window because the projection matrix is also set to project to only that small area.
Title: Re: SFGUI (0.1.0 released)
Post by: kamui on April 25, 2013, 10:32:10 am
I've a big problem and I didn't find anything, but I hope it's a known issue. I have a game using sfgui and i've make a popup to  let user enter an IP address. On my computer all works fine.

When i copy the exe on the computer of my wife, I try to enter my IP address and every character i write appears twice ! And the entry also contains the two characters so it's not a display problem !

I had to recompile all my dlls and I use them (sfml + sfgui) dynamically, and i think the problem is there. I would prefer not have to make different build for my game..

Tell me it's a known issue ;D

configuration : Intel Core i3-2310M CPU @ 2.10GHz 2.10GHz
RAM : 4Go
Seven SP1 64 bit
NVIDIA GeForce GT 520M


I can send you (by MP) a client, ask me if you need and tell me when you wanna try, i will activate the web services.
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on April 25, 2013, 12:00:51 pm
It's not a known problem, and we have never heard of it before. Can you reduce your code to a minimal example that we can compile ourselves? By minimal I mean one main() function with only the things needed to  reproduce the problem you encounter.
Title: Re: SFGUI (0.1.0 released)
Post by: kamui on April 25, 2013, 12:29:47 pm
I have not enough time today but tonight I'll make some tests and if I'm not able to make a simple example I'll try to make a minimal code that reproduce the problem. The fact that the problem does'nt appear on every computer make the debug very difficult even for you if my minimal code doesn't reproduce the error on your computer. Sorry to not do it now I'm at work this afternoon.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on May 15, 2013, 04:10:38 pm
How would one go about adding and rendering own new, custom widget? Engine has pure virtuals for all kind of widgets, do I just add my function there and in my widget do a dynamic_cast to see if it's my engine or not?

And I assume these things are horribly outdated:
http://redmine.boxbox.org/projects/sfgui/wiki/Widget_Interface_Design
http://redmine.boxbox.org/projects/sfgui/wiki/TODO_List

There is no expose or issensitive anymore, multi line labels and spin buttons were added already etc.
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on May 15, 2013, 04:38:59 pm
The simplest way to add rendering for a widget that only YOU will use in your own project would be to hardcode it into the widget's InvalidateImpl(). The only reason why the standard widgets use engines is for modularity reasons and not everybody might be content with the looks of default BREW ;). So unless you intend on making public your widget you don't need to go through the trouble of messing with engines. In the case you do make it public, you would want to modify BREW anyway so that the widget would have a standard rendering implementation.

And yes.... that documentation is horribly outdated :P dates back to sometime last summer I think lol...
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on May 15, 2013, 04:57:00 pm
I mean without recompiling SFG(or did you mean modifying BREW without recompile, if yes, then how), I would inherit BREW and add my own method which would use renderers Create methods like BREW now does and then dynamic_cast in my widget and throw curses exceptions if the running engine wasn't mine or inherited from it.
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on May 15, 2013, 05:16:50 pm
Like I said, if you implemented your own widget, write the rendering code directly into it's InvalidateImpl(). You would compile that code with the rest of your application and wouldn't have to rebuild SFGUI. You only need to modify the SFGUI source and hence rebuild it if you intend on making changes that you want to share with others (assuming of course that you want to make your widget themeable/engine customizable in the first place).
Title: Re: SFGUI (0.1.0 released)
Post by: Oliveira on May 19, 2013, 02:35:59 pm
Hi,
Just a little question about the LoadThemeFromFile method in SFGUI...
How can we create our own theme ?

Oliveira
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on May 19, 2013, 09:11:36 pm
Check the example theme file in the example/data directory.

This could also be helpful:
http://redmine.boxbox.org/projects/sfgui/wiki/Widget_Style_Properties
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on May 19, 2013, 09:16:40 pm
This seems more complete:
http://sfgui.sfml-dev.de/p/docs/style_reference
Title: Re: SFGUI (0.1.0 released)
Post by: Oliveira on May 19, 2013, 09:40:35 pm
Nice :)

Thanks a lot ! :D
Title: Re: SFGUI (0.1.0 released)
Post by: Turbine on June 08, 2013, 02:19:57 am
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?
Title: Re: SFGUI (0.1.0 released)
Post by: torey0 on June 10, 2013, 04:53:47 am
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?
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on June 10, 2013, 05:30:09 am
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.
Title: Re: SFGUI (0.1.0 released)
Post by: torey0 on June 10, 2013, 05:59:58 am
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++.
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on June 10, 2013, 06:24:44 am
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 ;D.
Title: Re: SFGUI (0.1.0 released)
Post by: torey0 on June 10, 2013, 07:11:17 pm
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  ;D
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on July 08, 2013, 04:22:20 am
You've been publicly criticized, congrats:
http://www.gamedev.net/blog/1682/entry-2256533-most-gui-libraries-are-terrible/
 ;D :P
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on July 08, 2013, 04:54:38 am
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 :P.
Title: Re: SFGUI (0.1.0 released)
Post by: FRex on July 08, 2013, 03:24:37 pm
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.
Title: Re: SFGUI (0.1.0 released)
Post by: binary1248 on July 08, 2013, 04:19:51 pm
libRocket - I scared Tank off from using it any more by showing him the asm code they embedded into their source, link here (https://github.com/lloydw/libRocket/blob/3a433977ba3b882d43ddec56fe80187c4315ce22/Source/Core/Math.cpp#L145).

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 :).
Title: Re: SFGUI (0.1.0 released)
Post by: Tank on August 07, 2013, 03:19:06 am
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:

Fixes:

Download

Downloads and other information can be found on the official website (http://sfgui.sfml-dev.de/).

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. ;)
Title: Re: SFGUI (0.1.1 released)
Post by: Kojay on August 07, 2013, 03:55:03 am
Good to see binary hasn't been left struggling all by himself  ;D

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).
Title: Re: SFGUI (0.1.1 released)
Post by: binary1248 on August 07, 2013, 06:53:57 am
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...
Title: Re: SFGUI (0.1.1 released)
Post by: Kojay on August 07, 2013, 07:08:10 am
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.
Title: Re: SFGUI (0.1.1 released)
Post by: binary1248 on August 07, 2013, 07:15:37 am
SFGUI also doesn't try to hold references to the SFML window. This would not only introduce really bad coupling, it would also make it harder for us to become independent of SFML if we chose to ;).
Title: Re: SFGUI (0.1.1 released)
Post by: Bitbridge on August 12, 2013, 05:50:56 pm
Hello,

I'm currently using SFML 2.x for a project and I'm also thinking about using Thor and SFGUI. I do use Visual Studio 2013 Preview and used Cmake to build/compile SFML (dynamic libs) and Thor which worked great.

However, when I try to generate a VS 2013 solution for SFGUI using Cmake it says it cannot find the SFML module. Now there are apparently 2 ways to solve this.

1: Set SFML_Dir to the directory containing "installed" SFML
When I do this (same when generating Thor) it just says it cannot find SFML and resets the SFML_DIR variable to "SFML_DIR-NOTFOUND". Some posts suggested also using SFML_ROOT and SFML_INCLUDE_DIR, which I tried and didn't help.

The SFML Directory, however, does not contain the SFMLConfig.cmake. If I rename the Config.cmake in SFML/Cmake and link to this folder it says that the SFML version is not supported (2).

2: Copy the FindSFML.cmake to the CMAKE_MODULE_PATH
When doing this, it says it cannot find specific SFML modules (graphics, system).

Here's a screenshot of my settings and the error.
(https://dl.dropboxusercontent.com/u/1316672/development/SFGUI.PNG)

I'm not really experienced with Cmake, but I hope we can find a solution. :)
Title: Re: SFGUI (0.1.1 released)
Post by: eXpl0it3r on August 12, 2013, 06:45:03 pm
That you'll have to define SFML_ROOT is said in the User Guide (http://sfgui.sfml-dev.de/p/docs/guide/building_from_source), unfortunately the part with actually finding SFML, isn't explain though.

For CMake to find SFML you'll have to add CMAKE_MODULE_PATH and set path to <path-to-sfml>/cmake/Modules/. Then you set SFML_ROOT to <path-to-sfml> and you should be fine. On the other hand you can manually install the FindSFML.cmake to <path-to-cmake>/share/cmake-2.8/Modules, just make sure to update every time it changes in SFML.
Title: Re: SFGUI (0.1.1 released)
Post by: Bitbridge on August 12, 2013, 07:08:34 pm
Thanks, that worked. Life can be so easy sometimes. ;)
Title: Re: SFGUI (0.1.1 released)
Post by: ChronicRat on August 25, 2013, 05:13:57 pm
I've just started to use SFGUI, and i have a question. How to check that event was proccessed in Desktop::Update(event)? For now if i'm dragging window by caption then i'm dragging game field too. Is there any possibility to check it?
Title: Re: SFGUI (0.1.1 released)
Post by: FRex on August 25, 2013, 05:40:09 pm
No. :-X
http://en.sfml-dev.org/forums/index.php?topic=6112.msg76198#msg76198
Maybe go bug tank about that and more gtk-ish callbacks like I do and he will change his mind. :-\

I had a thing to do something very much like flash does when it's in browser tab:
last click landed in gui = all events go to SFGUI(except super special events like closed, resized window etc.),
last click landed outside of gui = all events go to app(+ movements go to GUI event then because it makes sense)
the class that does these methods would wrap around desktop and never show it to client, and you'd add/remove using it's methods and it'd take weak widget ptr and add it to m_Solids if you added a 'solid' widget just now
Full code is on github, but, messy as hell so beware: https://github.com/FRex/ee/blob/master/src/ee/GUI/Core.cpp
This also fails(only place I know where it does, might fail more places) when top level widget is window that has a combobox in it and that combo extends its items list outside of window allocation, it'll the not detect clicks on these items that stick out.
Don't let the comment about coming 'proper fix' (a hack around SFG limitation really..) give you any hope tho. :P
Also, my repos(ee and Game) are MIT licensed.. so try not to just take(too much) code from it if you don't want to include a .txt file with your end app that has LICENSE file content in it to give me credit. ;)
And there should be check to see that result of lock() in checkForHit is valid shared_ptr.
bool alwaysSend(const sf::Event& event)
{
    switch (event.type)
    {
        default:
            return false;
        case sf::Event::Closed:
        case sf::Event::GainedFocus:
        case sf::Event::LostFocus:
        case sf::Event::Resized:
        case sf::Event::MouseLeft:
        case sf::Event::MouseEntered:
            return true;
    }
}

void GUICore::update(float seconds)
{
    m_Desktop.Update(seconds);
}

bool GUICore::handleEvent(const sf::Event& eve)
{
    //TODO: improve here
    if(eve.type==sf::Event::MouseMoved)//always handle mouse movements..(?)
    {
        m_Desktop.HandleEvent(eve);
    }
    if(eve.type==sf::Event::MouseButtonPressed/*&&eve.mouseButton.button==sf::Mouse::Left*/)//cmted for now..
    {
        checkForHit(sf::Vector2f(static_cast<float>(eve.mouseButton.x),static_cast<float>(eve.mouseButton.y)));
    }
    if(m_Active)
    {
        m_Desktop.HandleEvent(eve);
        return alwaysSend(eve);//special event
    }
    if(eve.type==sf::Event::MouseButtonPressed)//hack for combo boxes with long item lists
    {
        //m_Desktop.HandleEvent(eve);//it caused other bug which fix fixes this one too, if long combo lists come there can be proper fix later
    }
    return true;// !m_Active == true
}

void GUICore::checkForHit(sf::Vector2f pos)
{
    m_Active=true;

    for(auto it=m_Solid.begin();it!=m_Solid.end();++it)
    {
        if((*it).lock()->IsGloballyVisible() && (*it).lock()->GetAllocation().contains(pos)) return;
    }
    m_Active=false;
}
Title: Re: SFGUI (0.1.1 released)
Post by: ChronicRat on August 25, 2013, 05:50:55 pm
Ok, thanks. So no floating or resizeable windows to user will be. =) Creating own check system is too much cost.
Title: Re: SFGUI (0.1.1 released)
Post by: ChronicRat on September 01, 2013, 04:49:28 pm
There is any standard possibility to automatic scroll down to the end? I have log window and i need to see last posted messages without manual scroll by mouse.
Title: Re: SFGUI (0.1.1 released)
Post by: binary1248 on September 01, 2013, 05:08:06 pm
Just make sure the adjustment is set to its maximum every time it changes with OnChange.
Title: Re: SFGUI (0.1.1 released)
Post by: ChronicRat on September 01, 2013, 05:48:40 pm
Thanks, it works:
       
        mScrolledWindow->Refresh();
        const sfg::Adjustment::Ptr& scroll = mScrolledWindow->GetVerticalAdjustment();
        scroll->SetValue(scroll->GetUpper());
 
But will be nice to make it by one command.

upd: post edited, no questions anymore. =)
Title: Re: SFGUI (0.1.1 released)
Post by: two-tone- on September 18, 2013, 12:44:35 am
Question, will there be a tutorial on how to use SFGUI in the future?
Title: Re: SFGUI (0.1.1 released)
Post by: binary1248 on September 18, 2013, 01:21:53 am
If by tutorial you mean our example source code with slightly more comments written in pretty HTML and CSS so people can read them better in their internet browser instead of source code editor... yeah maybe. If you are expecting prose text that is 20 times more verbose than the code, you might be out of luck.
Title: Re: SFGUI (0.1.1 released)
Post by: infinitebox on November 18, 2013, 08:55:39 am
That you'll have to define SFML_ROOT is said in the User Guide (http://sfgui.sfml-dev.de/p/docs/guide/building_from_source), unfortunately the part with actually finding SFML, isn't explain though.

For CMake to find SFML you'll have to add CMAKE_MODULE_PATH and set path to <path-to-sfml>/cmake/Modules/. Then you set SFML_ROOT to <path-to-sfml> and you should be fine. On the other hand you can manually install the FindSFML.cmake to <path-to-cmake>/share/cmake-2.8/Modules, just make sure to update every time it changes in SFML.

Im also having trouble with this. After doing what you've explained, I'm now getting a "Could NOT find SFML (missing: SFML_GRAPHICS_LIBRARY SFML_WINDOW_LIBRARY SFML_SYSTEM_LIBRARY)" error in CMake.

The call stack shows:
CMakeLists.txt:22 (find_package)



UPDATE: nvm. my problem was my lib files were in different directories :P
Title: Re: SFGUI (0.1.1 released)
Post by: eXpl0it3r on November 18, 2013, 09:03:21 am
I haven't built SFML as of late, not sure if the CMake scripts got a change, but it sounds rather that your <path-to-sfml> on SFML_ROOT is not set right.
Does the specified directory contain the lib and include directories of SFML?
Title: Re: SFGUI (0.1.1 released)
Post by: infinitebox on November 18, 2013, 09:04:45 am
I haven't built SFML as of late, not sure if the CMake scripts got a change, but it sounds rather that you're <path-to-sfml> on SFML_ROOT is not set right.
Does the specified directory contain the lib and include directories of SFML?
I had my lib files in different directories so CMake couldn't find them :P (it was a custom VS2013 build).
Title: Re: SFGUI (0.1.1 released)
Post by: ChronicRat on November 18, 2013, 09:28:43 am
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.
Title: Re: SFGUI (0.1.1 released)
Post by: eXpl0it3r on November 18, 2013, 09:32:19 am
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... ???
Title: Re: SFGUI (0.1.1 released)
Post by: binary1248 on November 18, 2013, 09:39:11 am
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? :P
Title: Re: SFGUI (0.1.1 released)
Post by: Laurent on November 18, 2013, 09:46:35 am
Quote
Maybe an SFMLConfig.cmake or sfml-config.cmake?
Where is the pull request? :P
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on November 22, 2013, 02:54:46 pm
SFGUI 0.2.0 released

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

Enhancements:
Fixes:

WEBSITE http://sfgui.sfml-dev.de/
Title: Re: SFGUI (0.2.0 released)
Post by: eXpl0it3r on November 22, 2013, 03:01:24 pm
HAX! ;D

You forgot one point: Made a nicer website. ;)
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on November 22, 2013, 03:01:50 pm
Thanks. ;)
Title: Re: SFGUI (0.2.0 released)
Post by: FRex on November 22, 2013, 04:16:31 pm
Quote
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:
Quote
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: :P
Quote
Implemented two backend renderers (one uses vertex buffer objects, the other client-side vertex arrays).
I'm going to check it out now.
Title: Re: SFGUI (0.2.0 released)
Post by: Nexus on November 22, 2013, 10:20:49 pm
Hey, that website background is stolen from me (http://www.bromeon.ch/libraries) :P

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?
Title: AW: Re: SFGUI (0.2.0 released)
Post by: eXpl0it3r on November 22, 2013, 11:39:09 pm
Hey, that website background is stolen from me (http://www.bromeon.ch/libraries) :P
Did you say something? I only hear NOISE. :P

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. ;)
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on November 25, 2013, 08:42:55 am
Quote
Did you say something? I only hear NOISE. :P
It indeed looks like yours. However it's just the GIMP noise filter to make the background less boring. :)

Quote
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).
Title: Re: SFGUI (0.2.0 released)
Post by: FRex on November 25, 2013, 09:44:12 pm
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? :-\
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on November 26, 2013, 04:18:04 pm
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.
Title: Re: SFGUI (0.2.0 released)
Post by: FRex on November 26, 2013, 04:39:21 pm
Quote
I don't understand your second issue.
Quote
    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...
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on November 26, 2013, 04:43:40 pm
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.
Title: Re: SFGUI (0.2.0 released)
Post by: FRex on November 26, 2013, 04:51:26 pm
Right, I meant all widgets in all desktops. It still feels meh-y though so I'm doing some loud (wishful) thinking. ::)
Are you excited about (my) first attempt of (semi) complete Lua binding that is currently in progress? :P ;D
Title: Re: SFGUI (0.2.0 released)
Post by: r0d on December 03, 2013, 03:00:45 pm
Hello,

I want to test SFGUI, but I have problems to compile it. I'm on windows 7 with VS 2013 express ed.
I downloaded the last release: on this page (https://github.com/TankOs/SFGUI), I downloaded the zip file (the button on the right).
I also downloaded the last release of SFML (2.1), but only the "user package" (only binaries and include files).
I managed to generate the VS projects files for SFGUI with cmake.
But when I compile (ALL_BUILD), I got some link errors about the sf::String::begin() fonction that is unresolved:
Quote
2>Engine.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::_String_const_iterator<class std::_String_val<struct std::_Simple_types<unsigned int> > > __cdecl sf::String::begin(void)const " (__imp_?begin@String@sf@@QEBA?AV?$_String_const_iterator@V?$_String_val@U?$_Simple_types@I@std@@@std@@@std@@XZ) referenced in function "public: class sf::Vector2<float> __cdecl sfg::Engine::GetTextMetricsA(class sf::String const &,class sf::Font const &,unsigned int)const " (?GetTextMetricsA@Engine@sfg@@QEBA?AV?$Vector2@M@sf@@AEBVString@4@AEBVFont@4@I@Z)

But I looked in SFML/String.hpp  and this function is well declared (indeed there is 2 version, one returns an iterator, an the other a const iterator).

So first of all, I wanted to bring to your attention this little problem.
And now, what must I do? Do you think I have to download the source code of SFML and compile it?

Title: Re: SFGUI (0.2.0 released)
Post by: binary1248 on December 03, 2013, 03:11:39 pm
There is no pre-compiled version of SFML available for Visual Studio 2013 (yet). So it makes sense that you need to compile SFML for Visual Studio 2013 instead of using something for an older version that probably doesn't work ;). If you are brave you can give the SFML Installer (http://en.sfml-dev.org/forums/index.php?topic=13722.0) a try. It should do it for you automatically. No guarantees though ;D.
Title: Re: SFGUI (0.2.0 released)
Post by: r0d on December 03, 2013, 04:03:18 pm
Thank you binary4E0,

I downloaded the SFML sources and compiled it with vs2013 compilator, and now every thing is ok.
Thank you :)
Title: Re: SFGUI (0.2.0 released)
Post by: AxelRantila on January 24, 2014, 10:24:40 am
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).
But will we still be able use SFGUI with SFML even after it is decoupled? I haven't SFGUI yet, but I want to be able to use it with SFML even if it is decoupled
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on January 24, 2014, 10:31:43 am
Yes, you will be able to use SFGUI with SFML. There will even be an adapter for SFML included, no worries. :)
Title: Re: SFGUI (0.2.0 released)
Post by: eigenbom on January 30, 2014, 12:02:25 am
Why are you spending time decoupling it from SFML? There are already so many other cross-lib GUI kits out there, and I think the main attraction of SFGUI is that it works easily with SFML. But now you're going to have to duplicate SFML concepts at a higher level (Image, Vector, blah) in order to abstract it. GUI kits like Gwen, for instance, annoy me because the adapters for SFML/SDL/whatever never seem to be up to date - simply because there's not enough man power to maintain them all.
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on January 30, 2014, 09:20:08 am
Quote
Why are you spending time decoupling it from SFML?
Because at least I need it in projects that don't use SFML. Besides of that, we had to do a lot of workarounds to work flawlessly together with SFML, and we want to avoid spending time on such things.
Title: Re: SFGUI (0.2.0 released)
Post by: binary1248 on January 30, 2014, 10:41:16 am
Why are you spending time decoupling it from SFML?
As you already said yourself, it costs man power to keep it in sync with SFML considering we don't only have an adapter to maintain, so making it more or less independent of SFML will save us time that we can invest in other areas.

There are already so many other cross-lib GUI kits out there
Yeah... I used many of them, also in conjunction with SFML before I discovered SFGUI all those years ago, and quite frankly they were all horrible. So I guess we can use this opportunity to give people something that is... well... simple and fast to use with their existing frameworks.

and I think the main attraction of SFGUI is that it works easily with SFML.
Decoupling SFGUI from SFML does not imply that it won't be as easy to use with SFML as it was before... It might even be that from your standpoint you wouldn't even have to change a single line of code and it would just continue to work. It is more of an internal restructuring.

But now you're going to have to duplicate SFML concepts at a higher level (Image, Vector, blah) in order to abstract it.
We already have our own version of many SFML concepts just to keep performance up and even have to work around those that we find annoying.

GUI kits like Gwen, for instance, annoy me because the adapters for SFML/SDL/whatever never seem to be up to date - simply because there's not enough man power to maintain them all.
If you look at the work being done on them, I don't think it is about manpower as much as it is about interest. Nobody who is capable cares enough about the adapters to keep them up to date.

If the case is that not much work is being done on them in the first place, then you can't expect the adapters to work anyway.
Title: Re: SFGUI (0.2.0 released)
Post by: eigenbom on January 30, 2014, 10:06:23 pm
Oh I see, well needing it to be on another platform for your own use sounds like the best reason to me. In any case, good luck guys, and I look forward to seeing what you come up with. :)
Title: Re: SFGUI (0.2.0 released)
Post by: Tank on February 06, 2014, 02:38:15 pm
SFGUI 0.2.1 released.

Enhancements:
Fixes:

Grab it while it's hot!

WEBSITE http://sfgui.sfml-dev.de/
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 12, 2014, 12:56:17 pm
Woow, really interesting ^^ !

And last version with GLEW, just perfect for my project ^^ !

I started to code my own GUI for my multiplayer game project, but I think that your library could be really usefull in this case ^^ !

I'll test it, I have to see how I can use my own design with it ^^ !

EDIT : I have some errors when building (Windows, SFML 2.0 or MinGW 4.7.3 not supported ?) :

Scanning dependencies of target sfgui
[  1%] Building CXX object CMakeFiles/sfgui.dir/src/SFGUI/Adjustment.cpp.obj
In file included from D:\Dossier personnel\dev\SFGUI-0.2.1\src\SFGUI\Adjustment.
cpp:1:0:
D:/Dossier personnel/dev/SFGUI-0.2.1/include/SFGUI/Adjustment.hpp:18:3: error: l
ooser throw specifier for 'virtual sfg::Adjustment::~Adjustment()'
In file included from D:/Dossier personnel/dev/SFGUI-0.2.1/include/SFGUI/Adjustm
ent.hpp:3:0,
                 from D:\Dossier personnel\dev\SFGUI-0.2.1\src\SFGUI\Adjustment.
cpp:1:
D:/Dossier personnel/dev/SFGUI-0.2.1/include/SFGUI/Object.hpp:22:11: error:   ov
erriding 'virtual sfg::Object::~Object() noexcept (true)'
CMakeFiles\sfgui.dir\build.make:57: recipe for target 'CMakeFiles/sfgui.dir/src/
SFGUI/Adjustment.cpp.obj' failed
mingw32-make[2]: *** [CMakeFiles/sfgui.dir/src/SFGUI/Adjustment.cpp.obj] Error 1

CMakeFiles\Makefile2:62: recipe for target 'CMakeFiles/sfgui.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/sfgui.dir/all] Error 2
Makefile:115: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
 
Title: Re: SFGUI (0.2.1 released)
Post by: ChronicRat on February 12, 2014, 03:37:43 pm
Look here for required compilers: http://sfgui.sfml-dev.de/p/docs/guide/installing
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 12, 2014, 05:02:33 pm
Look here for required compilers: http://sfgui.sfml-dev.de/p/docs/guide/installing

I already saw this before building ! But don't know with that if SFML 2.0 or GCC 4.7.3 is the problem with me !?

Quote
Code::Blocks 12.11 release contains GCC 4.7.1 which is not compatible with SFGUI
GCC 4.7.3 ?

Quote
Continue by downloading and installing SFML 2.1 and GLEW
SFML 2.0 is supported ?

I ask this because I don't really want to spend time to download and build SFML 2.1 if GCC 4.7.3 cannot be used ^^ ! And that would be a big problem for me because I can't use GCC 4.8+ (bug with one library I use) !
Title: AW: SFGUI (0.2.1 released)
Post by: eXpl0it3r on February 12, 2014, 05:27:08 pm
The difference between 4.7.1 and 4.7.3 are only small bug fixes. The difference between 4.7.x and 4.8.x are complete C++11 support, which SFGUI makes use of.

Since you'll have to rebuild SFML anyways (to match your compiler) go with the source directly. The master branch is essentially always stable.

What bug does which library have with GCC 4.8.x?

Btw. I can recommend to get the bundle from MinGW Builds. ;)
Title: Re: SFGUI (0.2.1 released)
Post by: binary1248 on February 12, 2014, 05:41:15 pm
I can't use GCC 4.8+ (bug with one library I use)
And that bug would be...? I highly doubt that it is GCC's fault. If it is released, then it is in a really stable state. If this library you use is open source you could try to fix the problem yourself, or if the developers care enough about GCC compatibility in case it is closed source you could try to convince them to fix the bug.

Not being able to use a standard conforming compiler because some library doesn't work (anymore) must be one of the sadder reasons I've seen.
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 12, 2014, 05:42:27 pm
Little mistake ! With GCC 4.8+ it's not a problem with a library, but directly with my IDE >< !

I use Eclipse CDT and I tried many months ago but couldn't build a program with c++11 or c++0x activated with GCC 4.8+ (don't remember all the errors ^^, but because of that I switched to GCC 4.7.3) !
Maybe I can now try to rebuild everything with all the last versions !

Quote
Not being able to use a standard conforming compiler because some library doesn't work (anymore) must be one of the sadder reasons I've seen.

I can understand ! It's just that I'm really a beginner when it comes to Makefile, Lib, or everything else that don't work at first try ^^ !
Title: Re: SFGUI (0.2.1 released)
Post by: binary1248 on February 12, 2014, 06:08:50 pm
I don't know exactly when and with what version you last tried, but a simple search on Google showed that a lot of people were already able to get Eclipse CDT working with C++11.

https://www.google.com/search?q=Eclipse+CDT+GCC+4.8
http://wiki.eclipse.org/CDT/User/FAQ#CDT_does_not_recognize_C.2B.2B11_features
Title: Re: SFGUI (0.2.1 released)
Post by: Lolilolight on February 12, 2014, 10:17:26 pm
I use code::blocks and c++11 works, Eclipse is a bit more complicated to use I think, because there are more menus.

The only inconvenient is that I have to switch of compilator if I want to compile in 32 bits or in 64 bits.
(With tdm-gcc the flag -m32 doesn't work, maybe there's another way to configure this with code::block but all the method I tested when I've checked on the forum didn't work so...)

I keep going to use two compilator. (tdm-gcc-32 and tdm-gcc-64 version 4.8)

Have you a 32 bits or a 64 bits compilators of tdm gcc ? (It's very possible that you have an incompatibility, I also had problems)

But What error messages did you have ?
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 12, 2014, 10:55:56 pm
But What error messages did you have ?

I don't remember, it was so much time ago ^^ !
But I'll see if there are any problem, I'll try to use the last version of MinGW and rebuild all the libs. It will take some time, so this weekend I think ^^ !
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 15, 2014, 10:20:27 am
Well, already one problem with this new MinGW (GCC 4.8.1) installation :

- LibOVR (OculusRift SDK) : unrecognized command line option "-municode" when building (using Msys1.0)
I don't found the solution for now !

That's not the error I mentioned earlier !

EDIT : just tried to delete "-municode" to see what happen, and now it's "localtime_s was not declared in this scope" for one file of the lib (don't know if it's linked) ! Why is it always so complicated to build a lib >< ?

Sorry, this LibOVR has nothing to do with your SFGUI, but I really want to test and use your work ^^ ! And this first approach with the last MinGW distribution is not very pleasant ^^' !

Also I have a question about boxes design for SFGUI : we have to use images in order to use a special background ? If yes, does it have some kind of 9-patch (9-slice-scaling) support ?

Title: Re: SFGUI (0.2.1 released)
Post by: binary1248 on February 15, 2014, 10:52:19 am
- LibOVR (OculusRift SDK) : unrecognized command line option "-municode" when building (using Msys1.0)
I don't found the solution for now !
The solution is... install the same kind of MinGW as you had before. -municode is a mingw-w64 flag which obviously won't be present on mingw32. You can't just replace something with something else just because it has a greater version number. MinGW is, believe it or not, quite easy to upgrade. You just replace all files and rebuild everything. The hard part is figuring out what you actually have on your hard disk to replace...

http://sourceforge.net/apps/trac/mingw-w64/wiki/Unicode%20apps#Issues
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 15, 2014, 11:04:05 am
- LibOVR (OculusRift SDK) : unrecognized command line option "-municode" when building (using Msys1.0)
I don't found the solution for now !
The solution is... install the same kind of MinGW as you had before. -municode is a mingw-w64 flag which obviously won't be present on mingw32. You can't just replace something with something else just because it has a greater version number. MinGW is, believe it or not, quite easy to upgrade. You just replace all files and rebuild everything. The hard part is figuring out what you actually have on your hard disk to replace...

I know that it's really simple to use any version of MinGW ^^ ! But really I don't know which one I need to choose now ^^ ! I can't use my older version where everything works fine because it's GCC 4.7 and can't use it with SFGUI ! Also there are MinGW, MingW-w64, TDM-GCC, ... !
(I tried last version of TDM-GCC, no Msys installed with it, I don't know if it has to be a linked module)

Oh, and I need to use and build libs for win32 (not x64) ! About that, I don't understand why I succesfully built the LibOVR with this older version of MinGW when I think about it !
Title: Re: SFGUI (0.2.1 released)
Post by: eXpl0it3r on February 15, 2014, 11:22:22 am
I usually go with one of these: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-posix/

I choose posix since the win32 thread model doesn't support std::thread, where as the posix one makes it possible via winpthread. ;)
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 15, 2014, 11:36:58 am
I usually go with one of these: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/32-bit/threads-posix/

I choose posix since the win32 thread model doesn't support std::thread, where as the posix one makes it possible via winpthread. ;)

LibOVR : successful build with this version !


This is a mingw-w64 version, how can I use it for x86 only ? Do I need to add to path "i686-w64-mingw32\bin" ?
Title: Re: SFGUI (0.2.1 released)
Post by: eXpl0it3r on February 15, 2014, 11:59:30 am
While the name is MinGW-w64 and the origin of it is that they wanted a MinGW version for x64 applications, but the MinGW-w64 can still be used as x86 compiler, in fact if you had looked closely at the URL above, you'd have noticed that you're already in the 32-bit sub-directory, thus your compiler is already producing x86 applications only. ;)
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 15, 2014, 12:07:32 pm
While the name is MinGW-w64 and the origin of it is that they wanted a MinGW version for x64 applications, but the MinGW-w64 can still be used as x86 compiler, in fact if you had looked closely at the URL above, you'd have noticed that you're already in the 32-bit sub-directory, thus your compiler is already producing x86 applications only. ;)

Ohh right, thank you (I'm really lost for everything unless programming with C++ and my IDE ^^') !
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 15, 2014, 02:44:15 pm
Do you know how to build Glew Static with MinGW ? It produce only the shared by default, and it failed to build SFGUI with this libglew32.a !
Title: Re: SFGUI (0.2.1 released)
Post by: binary1248 on February 15, 2014, 04:05:46 pm
So... why can't you just use the one provided with SFML?
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 15, 2014, 04:25:39 pm
So... why can't you just use the one provided with SFML?

I think that's a really great question xD !

I didn't know that SFML already had a mingw precompiled version of glew ^^ !

Everything seems to be Ok now ! There is only one lib that I can't rebuild now because I need his creator (NazaraEngine), but everything else has been built with this new GCC version !

Thank you for your help !

Now it's time to test this interesting SFGUI ^^ !
I asked a question about SFGUI boxes earlier : we have to use images in order to have a special background ? If yes, does it have some kind of 9-patch (9-slice-scaling) support ?
Title: Re: SFGUI (0.2.1 released)
Post by: eXpl0it3r on February 15, 2014, 08:22:50 pm
I asked a question about SFGUI boxes earlier : we have to use images in order to have a special background ? If yes, does it have some kind of 9-patch (9-slice-scaling) support ?
SFGUI doesn't have a bitmap renderer, thus you currently only use the normal renderer...
Title: Re: SFGUI (0.2.1 released)
Post by: Dragonic on February 16, 2014, 10:58:12 am
I asked a question about SFGUI boxes earlier : we have to use images in order to have a special background ? If yes, does it have some kind of 9-patch (9-slice-scaling) support ?
SFGUI doesn't have a bitmap renderer, thus you currently only use the normal renderer...

Ok !
I tried the Window example, that was perfect !
(maybe you should put "m_window.setVerticalSyncEnabled(true);" in your examples, this could be better for the CPU ^^)

For my 9-patch problem, maybe I could try to "merge" my 9-patch rendering with SFGUI boxes ! I have to see how to change background color in order to make them invisible ! (Is there an example with style modifications ?)
Title: AW: Re: SFGUI (0.2.1 released)
Post by: eXpl0it3r on February 16, 2014, 11:14:30 am
I have to see how to change background color in order to make them invisible ! (Is there an example with style modifications ?)
Look at the SFGUI website and the example that ship with the source. ;)
Title: Re: SFGUI (0.2.1 released)
Post by: Tank on February 17, 2014, 01:20:46 pm
Quote
in your examples, this could be better for the CPU
We also use the examples for profiling, so we are indeed interested in the highest possible FPS.
Title: Re: SFGUI (0.2.1 released)
Post by: Lolilolight on February 17, 2014, 02:14:39 pm
Interressant project, I'll certainly search some inspiration in your code to create some gui with my framework and adapt it with my listener system to do something similar to QT. (But I'll not rewrite Qt, the purpose is to do something newest with the new c++11 functionnality, the necessity to generate moc-files was a bit annoying)

Title: Re: SFGUI (0.2.2 released)
Post by: Tank on February 19, 2014, 04:24:05 pm
0.2.2 released


This is mainly a bugfix release. There was a rather critical issue in the CMake config file that did not add GLEW's include directory to the compiler search paths. That's now solved.

For the complete list of changes check the changelog (https://github.com/TankOs/SFGUI/blob/0.2.2/CHANGELOG).

Important: For 0.2.2 you need the current SFML Git version. If you use SFML 2.1, stick to version 0.2.0 for now.


WEBSITE http://sfgui.sfml-dev.de/
Title: Re: SFGUI (0.2.2 released)
Post by: Dragonic on February 20, 2014, 09:59:13 am
0.2.2 released


This is mainly a bugfix release. There was a rather critical issue in the CMake config file that did not add GLEW's include directory to the compiler search paths. That's now solved.

For the complete list of changes check the changelog (https://github.com/TankOs/SFGUI/blob/0.2.2/CHANGELOG).

Important: For 0.2.2 you need the current SFML Git version. If you use SFML 2.1, stick to version 0.2.0 for now.


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

Maybe because of that I need to do something else with cmake configuration , because I have an error when building with mingw32-make !

(http://image.noelshack.com/fichiers/2014/08/1392886550-console.jpg)

"GL/glew.h: No such file or directory" ?

For cmake, I have :
GLEW_INCLUDE_DIR = "D:\dev2\SFML-2.1\extlibs\headers"
GLEW_INCLUDE_PATH = "D:\dev2\SFML-2.1\extlibs\headers"
GLEW_LIBRARY = "D:\dev2\SFML-2.1\extlibs\libs-mingw\x86\libglew.a"

EDIT : CMakeCache : http://pastebin.com/WrAY0te0
Title: Re: SFGUI (0.2.2 released)
Post by: Tank on February 20, 2014, 11:00:52 am
Well, SFML seems to ship an own FindGLEW.cmake file which uses different variables names than the original FindGLEW in the CMake distribution... For now, to workaround the issue, please set GLEW_INCLUDE_PATH to the same value as GLEW_INCLUDE_DIR.
Title: Re: SFGUI (0.2.2 released)
Post by: Dragonic on February 20, 2014, 11:44:22 am
[...] For now, to workaround the issue, please set GLEW_INCLUDE_PATH to the same value as GLEW_INCLUDE_DIR.

This is already the case ^^ !


For cmake, I have :
GLEW_INCLUDE_DIR = "D:\dev2\SFML-2.1\extlibs\headers"
GLEW_INCLUDE_PATH = "D:\dev2\SFML-2.1\extlibs\headers"
GLEW_LIBRARY = "D:\dev2\SFML-2.1\extlibs\libs-mingw\x86\libglew.a"

EDIT : CMakeCache : http://pastebin.com/WrAY0te0
Title: Re: SFGUI (0.2.2 released)
Post by: Tank on February 20, 2014, 02:22:10 pm
Sorry, please set GLEW_INCLUDE_DIRS accordingly. I've already reported this in the general section of this forum, but any changes will soonest be available in SFML 2.2, and its ETA is unknown. Semantic versioning anyone? ;-) (http://semver.org/)

Seems like it makes sense to push out 0.2.3 with both GLEW_INCLUDE_PATH and GLEW_INCLUDE_DIRS. Sorry for any inconvenience.
Title: Re: SFGUI (0.2.3 released)
Post by: Tank on February 20, 2014, 02:39:43 pm
0.2.3 released


This is mainly a bugfix release. We've added a workaround to maintain compatibility with SFML's cmake/Modules path which contains a custom FindGLEW.cmake file that uses GLEW_INCLUDE_PATH instead of the built-in CMake's module's GLEW_INCLUDE_DIRS.

Changelog (https://github.com/TankOs/SFGUI/blob/0.2.3/CHANGELOG).

Important: For 0.2.3 you need the current SFML Git version. If you use SFML 2.1, stick to version 0.2.0 for now.


WEBSITE http://sfgui.sfml-dev.de/
Title: Re: SFGUI (0.2.3 released)
Post by: Lolilolight on February 27, 2014, 06:14:13 pm
Hi, I have also a problem when I try to use glew in another project than SFML.

When I compile a project which use SFML and glew, it gives me undefined references errors. (Since I use tdm-gcc)

But it works well with opengl, but not with glew.

I think I'll be forced to removes the glew functions.





Title: Re: SFGUI (0.2.3 released)
Post by: binary1248 on February 27, 2014, 06:22:46 pm
Hi, I have also a problem when I try to use glew in another project than SFML.

When I compile a project which use SFML and glew, it gives me undefined references errors. (Since I use tdm-gcc)

But it works well with opengl, but not with glew.

I think I'll be forced to removes the glew functions.
? ? ? ? ? ? ? ?

So... what has this got to do with SFGUI? The problem has been fixed and it was merely a CMake configuration mishap. SFML can be used side by side with GLEW if you know how to link them into your project. This has been discussed so many times before... If you have a specific problem with something unrelated to SFGUI please start a new thread.
Title: Re: SFGUI (0.2.3 released)
Post by: Theshooter7 on April 07, 2014, 03:46:52 am
I am receiving compile errors after I upgraded from 0.1.1 at long last.
2>D:\SFGUI-0.2.3\include\SFGUI/Signal.hpp(29): error C2065: 'default' : undeclared identifier
2>D:\SFGUI-0.2.3\include\SFGUI/Signal.hpp(29): error C2253: 'Signal' : pure specifier or abstract override specifier only allowed on virtual function
2>D:\SFGUI-0.2.3\include\SFGUI/Signal.hpp(30): error C2059: syntax error : ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Signal.hpp(30): error C2238: unexpected token(s) preceding ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Signal.hpp(31): error C2059: syntax error : ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Signal.hpp(31): error C2238: unexpected token(s) preceding ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(18): error C2065: 'default' : undeclared identifier
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(18): error C2253: 'Object' : pure specifier or abstract override specifier only allowed on virtual function
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(22): error C2065: 'default' : undeclared identifier
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(22): error C2258: illegal pure syntax, must be '= 0'
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(29): error C2059: syntax error : ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(29): error C2238: unexpected token(s) preceding ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(33): error C2059: syntax error : ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Object.hpp(33): error C2238: unexpected token(s) preceding ';'
2>D:\SFGUI-0.2.3\include\SFGUI/Adjustment.hpp(18): error C2065: 'default' : undeclared identifier
2>D:\SFGUI-0.2.3\include\SFGUI/Adjustment.hpp(18): error C2258: illegal pure syntax, must be '= 0'
2>..\src\SFGUI\Adjustment.cpp(19): error C2259: 'sfg::Adjustment' : cannot instantiate abstract class
2>          due to following members:
2>          'sfg::Adjustment::~Adjustment(void)' : is abstract
2>          D:\SFGUI-0.2.3\include\SFGUI/Adjustment.hpp(18) : see declaration of 'sfg::Adjustment::~Adjustment'
I am getting this with Visual Studio 2012 Update 4. I have upgraded to the latest SFML Git version, and have rebuilt SFML and Glew (although these errors appear unrelated).

Any help? I've never seen a 'default' virtual specifier before, so am I missing some kind of compiler feature or something?
Title: Re: SFGUI (0.2.3 released)
Post by: Ixrec on April 07, 2014, 08:00:55 am
I would assume that's the C++11 "= default" feature, and Visual Studio 2012 definitely does not support C++11.
Title: Re: SFGUI (0.2.3 released)
Post by: eXpl0it3r on April 07, 2014, 08:28:51 am
From the official website:

Quote
Why isn't there support for older Visual Studio/GCC/whatever versions?
SFGUI makes use of modern C++11 features, such as range-based for loops, std::function, std::bind, move semantics and many more. If you're using a compiler that does not yet support those features, you won't be able to use SFGUI. Please upgrade your toolchain.

I'm not 100% certain, but I think VS 2013 should work.
Title: Re: SFGUI (0.2.3 released)
Post by: Theshooter7 on April 08, 2014, 05:04:28 am
I see. VS2012 did support the things listed (std::function, std::bind, etc.) but I know it's implementation was not 'complete'. Thus, it seems an upgrade is needed then. :(
Title: Re: SFGUI (0.2.3 released)
Post by: lolz123 on April 08, 2014, 05:48:55 am
I'm using VS2013, works perfectly for me! Just integrated it into D3D  :) Great lib!
Title: Why using RAII everywhere ?
Post by: Lolilolight on May 26, 2014, 12:54:21 pm
Hi!

There is a question that I would like to ask.

In sf::GUI. (and not only in sf::GUI but also in some other project like thor)

You are using RAII everywhere (even for function pointer and member variables)

If I want to create a gui I'm forcing to use an std::shared_pointer.

I don't thing automatic memory management is a part of the new standart of the c++11.
Memory management in a c++ class depends on the class semantic and have to be managed by the destructor and by the copy constructor and the operator= overload.

smart pointers have to be used only for non member variables and especially in an exception context exactely like the std::lock_guard class (to unlock the mutex event if an exception is generated)

So I don't understand the interest of using RAII everywhere. :/


Title: Re: SFGUI (0.2.3 released)
Post by: Grimshaw on May 26, 2014, 02:16:14 pm
Please teach us how it should be done :D
Title: Re: SFGUI (0.2.3 released)
Post by: Lolilolight on May 26, 2014, 02:26:07 pm
Me ?
I just learned to use smart pointers (=RAII) which try/catch clauses only and in the other cases to use the copy, move constructor, the operator= and the destuctor if it's necessary. (It depends on the semantic of the class, if the class have interna pointers and if the values of the internal pointers have to be copied or not and if the class have to create or delete the pointers)

It avoids to have too much abstraction. (I really hate that. :/)

The only exemple when I use RAII.

Resource* r = new Resource();
std::unique_ptr<Resource>(r);
try {
} catch {
}
 

And the std:::shared_pointer if you pass the pointer to another function in the try catch blocks.
Title: Re: SFGUI (0.2.3 released)
Post by: Grimshaw on May 26, 2014, 02:37:05 pm
We are blessed to receive your teachings :)
Title: Re: SFGUI (0.2.3 released)
Post by: Jesper Juhl on May 26, 2014, 03:52:44 pm
The only exemple when I use RAII.

Resource* r = new Resource();
std::unique_ptr<Resource>(r);
 
Why the intermediate variable "r"?

For C++11, just use:
  auto ptr = std::unique_ptr<Resource>(new Resource);

In C++14 you have an even better solution in the form of std::make_unique
Title: Re: SFGUI (0.2.3 released)
Post by: Lolilolight on May 26, 2014, 04:41:08 pm
Ok I can also do that...

Can't wait until the c++14.  :D
Title: Re: SFGUI (0.2.3 released)
Post by: Grimshaw on May 26, 2014, 07:52:52 pm
Yeah, I hope you are still around when it comes out so you can teach us some more new tricks :D It would be awesome.
Title: Re: SFGUI (0.2.3 released)
Post by: StormWingDelta on February 18, 2015, 01:04:47 am
This project still being updated?  Was hunting around for this and other GUIs to use with SFML and thought it might be useful for what I'm up to. :)
Title: Re: SFGUI (0.2.3 released)
Post by: eXpl0it3r on February 18, 2015, 01:07:20 am
Last commit (https://github.com/TankOs/SFGUI/commits/testing) Feb 4, 2015. Is it still being updated? ::)

Title: Re: SFGUI (0.2.3 released)
Post by: StormWingDelta on February 18, 2015, 01:09:28 am
lol guess it would have helped if I had looked in the comments section.   :-[
Title: Re: SFGUI (0.2.3 released)
Post by: Sub on February 18, 2015, 02:53:07 am
A lot can happen in two weeks  ;)
Title: Re: SFGUI (0.2.3 released)
Post by: Neomex on April 23, 2015, 06:49:09 pm
Could someone provide binaries for visual studio 2013? Pretty please?

I have spent last two hours getting cmake to work and now it doesn't compile :(

Error   1   error LNK1107: invalid or corrupt file: cannot read at 0x2E8   C:\ProgrammingLibraries\SFML-2.2\bin\sfml-graphics-d-2.dll   1   1   sfgui
Title: Re: SFGUI (0.2.3 released)
Post by: Jesper Juhl on April 23, 2015, 06:55:01 pm
Seriously?
You have to compile your own application; this means you have to know how compiling and linking works. Also, for anything except a toy app you'll most likely be using multiple libraries - do you really expect being able to find binaries for all of them built with your compiler of choice?
Learn how to build your own libs from source (now), once and for all, and be forever happier ;-)
Title: Re: SFGUI (0.2.3 released)
Post by: Neomex on April 23, 2015, 08:15:50 pm
do you really expect being able to find binaries for all of them built with your compiler of choice?
Yes, I expect every quality library to provide binaries, this should be automated to a one click process on the creators side.

No offence but you sounded douchey.
Title: Re: SFGUI (0.2.3 released)
Post by: Hiura on April 23, 2015, 08:20:15 pm
http://www.nightlybuilds.ch/project/show/5/SFGUI/ ?
Title: Re: SFGUI (0.2.3 released)
Post by: binary1248 on April 23, 2015, 08:27:22 pm
Yes, I expect every quality library to provide binaries, this should be automated to a one click process on the creators side.

No offence but you sounded douchey.
You know... he was just trying to prepare you for the actual task of using SFGUI ;). No offence, but with that kind of "library must make my life heaven" attitude you aren't going to get much done with SFGUI, so either get used to having to do a bit more yourself or turn around now and don't waste more of your precious time. ;)
Title: Re: SFGUI (0.2.3 released)
Post by: Jesper Juhl on April 23, 2015, 08:44:31 pm
do you really expect being able to find binaries for all of them built with your compiler of choice?
Yes, I expect every quality library to provide binaries, this should be automated to a one click process on the creators side.

So every library you use should provide precompiled binaries made with clang, gcc (various mingw versions of course),  visual studio (2010, 2012, 2015 - other versions), the Intel compiler and more?
And of course they should provide both 32 and 64bit versions of the lib for every compiler and both debug and release builds (and static + dynamic libs - of course).
And if they support more than one OS (or OS version - think XP vs Win 7 and different runtime libs) they should do the above for all platforms - naturally.

No offence but you sounded douchey.
I can live with that. But honestly, you should just learn to compile the libraries you need on the platform you need them with the compiler you use.
It really is no big deal.
The work you want to push onto library developers is, however, quite unreasonable...

And I really have no sympathy for your "I spent the last two hours" argument. If you think a problem that require two hours to solve is a big deal you are going to have some real problems going forward.
In my experience it's not uncommon to run into problems that take weeks of dedicated effort (studying, debugging, experimentation etc, with coworkers) to solve.  If you give up at 2 hours then I really don't know what to say.. And with as simple a problem as compiling a library even...
Title: Re: SFGUI (0.2.3 released)
Post by: shadowmouse on April 24, 2015, 06:12:57 pm
On a slightly different topic, can I just say how amazing this library looks? I'm planning my A level course work at the moment (which I'm of course going to ridiculously overdo) and this is perfect. To be honest, I'm surprised this does come as a part of sfml so you'd have sfml-graphics,sfml-audio,sfml-window,sfml-gui,sfml-network and sfml-system. The only thing that confuses me is that on the linking section of the website it seems to presume the use of CMake. I've never really looked into it, but as far as I know I've never used CMake (though code::blocks may use it when linking for all I know about it) and I didn't think it was necessary.
Title: Re: SFGUI (0.2.3 released)
Post by: Raincode on May 27, 2015, 03:36:46 pm
Hi,

I was just wondering: Is SFGUI suited as integrated gui-system for smaller games, using custom graphics for gui elements (e.g. own button base, hover, pressed)?

Because I really want to avoid having to create something like this on my own. Even though my current system works nicely for buttons only (modified version from SFML Book), once I try adding line edits I just get a big headache, completely failing with all the logic code. On top of that, I just can't find any extensive and good resources on the internet (P.S.: If you have something, please share).

I just don't want to start getting into it, if someone can tell me off the bat that sfgui won't work for what I want.

And if it's not the greatest, does any of these do the job?
    GWEN
    TGUI
    CEGUI
    Guichan
    libRocket
    Turbo Badger

Raincode
Title: Re: SFGUI (0.2.3 released)
Post by: eXpl0it3r on May 27, 2015, 04:05:10 pm
I was just wondering: Is SFGUI suited as integrated gui-system for smaller games, using custom graphics for gui elements (e.g. own button base, hover, pressed)?
No, or rather not yet. SFGUI currently only provides a simple "shape" rendered. A bitmap renderer has been unofficially in the works for a long time, but has yet to be finished.
Title: Re: SFGUI (0.2.3 released)
Post by: shadowmouse on May 27, 2015, 04:06:43 pm
Is that likely to be done within the next two years?
Title: Re: SFGUI (0.2.3 released)
Post by: StormWingDelta on May 27, 2015, 04:32:07 pm
Just wondering about something.  Are we able to make a bubble circle menu list?  Where each of the buttons and other things in the list is either a floating circle or part of one.  In my case I'm trying to setup a menu for clicking on things that is one center circle with a ring of smaller ones around it.  Just wondering if it could be done. :)
Title: AW: SFGUI (0.2.3 released)
Post by: eXpl0it3r on May 27, 2015, 05:24:43 pm
Not really, no.
Title: Re: SFGUI (0.2.3 released)
Post by: StormWingDelta on June 20, 2015, 07:37:04 pm
Been hunting through the examples and was wondering about something.  In some it doesn't use SFML to draw some things while in others there's so much in the file it is hard to tell what is doing what.  What's the simplest example in the bunch that lets you use both SFGUI and SFML in the same screen.  Where say you have half the screen for the menu made by SFGUI and half is for the play area in the game drawing like normal?
Title: Re: SFGUI (0.2.3 released)
Post by: eXpl0it3r on June 20, 2015, 07:58:56 pm
I don't fully follow. You just draw your SFML stuff and let SFGUI draw its own stuff. You don't need to do anything complicated to get it working. ;)
Title: Re: SFGUI (0.2.3 released)
Post by: StormWingDelta on June 20, 2015, 08:01:38 pm
I don't fully follow. You just draw your SFML stuff and let SFGUI draw its own stuff. You don't need to do anything complicated to get it working. ;)

OK was just wondering. :)

What I meant was SFGUI drawing on one part of the screen and SFML drawing on the other.  Seems as long as I don't get too complicated it should work fine. :)
Title: Re: SFGUI (0.3.0 released)
Post by: Tank on August 03, 2015, 09:20:42 am
SFGUI 0.3.0 was released -- Kudos to binary1248 for 98% of all the hard work. ;)

Find the changelog here: https://github.com/TankOs/SFGUI/blob/0.3.0/CHANGELOG
Find the download here: http://sfgui.sfml-dev.de/download/
Title: Re: SFGUI (0.3.0 released)
Post by: Nexus on August 03, 2015, 12:48:53 pm
Nice to see SFGUI is still actively developed! :)
Title: Re: SFGUI (0.3.0 released)
Post by: shadowmouse on August 03, 2015, 12:52:24 pm
You had to release an update just after I started making my own basic GUI system. Why? But seriously I'm glad that this is still being developed, it's an amazing project. SFML, Thor, SFGUI and LTBL2 and there's nothing you can't do.
Title: Re: SFGUI (0.3.0 released)
Post by: Tank on August 03, 2015, 01:21:34 pm
shadowmouse, a rendering issue was the only thing holding back the 0.3.0 release for, uhm, weeks, if not months. :P

Nexus, let's say it's still being maintained, primarily by binary1248.
Title: Re: SFGUI (0.3.0 released)
Post by: Hiura on August 03, 2015, 06:27:51 pm
Nice!  :D
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 09:58:44 am
; ; I can't install this for mac for the life of me, I am using Xcode and trying to build using cmake. I always get errors with glew (I downloaded blew), I wish the glew files were built in, and I could just build it using cmake directly as one file. It looks like a really good gui, if I could get it to build.
Title: Re: SFGUI (0.3.0 released)
Post by: eXpl0it3r on August 04, 2015, 10:04:40 am
Get the latest source code. GLEW isn't used anymore so you shouldn't get any errors about GLEW.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 11:27:39 am
Get the latest source code. GLEW isn't used anymore so you shouldn't get any errors about GLEW.
Oh sweet, thanks.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 12:14:33 pm
Get the latest source code. GLEW isn't used anymore so you shouldn't get any errors about GLEW.

I am kind of a noob at cmake, and github. The source code is all the files on github? https://github.com/TankOs/SFGUI here? How do I download them all at once. Can you sort of spell it out for me. Thank you vm
Title: Re: SFGUI (0.3.0 released)
Post by: eXpl0it3r on August 04, 2015, 12:49:42 pm
There's a big button called "Download ZIP"

(http://i.imgur.com/Zljgdkz.png)
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 09:28:01 pm
There's a big button called "Download ZIP"

(http://i.imgur.com/Zljgdkz.png)

rofl, my window was cutoff on the side
Title: Re: SFGUI (0.3.0 released)
Post by: Tank on August 04, 2015, 10:58:38 pm
There's also a download section at the website.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 11:04:49 pm
There's also a download section at the website.

I managed to install Xcode 2.3, I had 2.2 and had problems with 2.3. I then built sfgui using c-make, I built for X-code (the c-make actually worked!), I then clicked the project file, and tried running in x-code (the one built from c-make), got compile error. So I am trying to figure out where to go from here to get sf-gui working with Xcode
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 11:17:06 pm
so I guess I need to link this file
(http://i57.tinypic.com/24c5rvp.png)
to xcode project somehow, or another, I am trying to do right now
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 04, 2015, 11:45:35 pm
I recreated the  Xcode c-make file this time without examples checked, and when I ran the resulting project code in x-code, it successfully compiled, so that is where I am right now, I still haven't used sf-gui yet or any examples.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 05, 2015, 12:46:09 am
I recreated the  Xcode c-make file this time without examples checked, and when I ran the resulting project code in x-code, it successfully compiled, so that is where I am right now, I still haven't used sf-gui yet or any examples.

Can't seem to get it working with Xcode - any advice?
Title: Re: SFGUI (0.3.0 released)
Post by: eXpl0it3r on August 05, 2015, 01:03:50 am
Please use the edit function of the forum if you want to add something to a previous post instead of writing four posts in a row.

Also spend a bit more time on the problem before posting on the forum and be more patient with waiting for answers. There are only a small number of OS X developers here and none of them are much invested in SFGUI.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 05, 2015, 02:09:03 am
Please use the edit function of the forum if you want to add something to a previous post instead of writing four posts in a row.

Also spend a bit more time on the problem before posting on the forum and be more patient with waiting for answers. There are only a small number of OS X developers here and none of them are much invested in SFGUI.

Sounds good
Title: Re: SFGUI (0.3.0 released)
Post by: Tank on August 05, 2015, 08:21:41 am
Please paste which errors you get. You might also want to try out another generator besides Xcode.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 05, 2015, 08:42:06 am
Please paste which errors you get. You might also want to try out another generator besides Xcode.

Test - Cmake - Unix - Terminal Install
C-Make
Unix Makefiles
Use default native compilers
SFGUI_BUILD_EXAMPLES (check marked)
SFGUI_BUILD_SHARED_LIBS (check marked)
SFGUI_INCLUDE_FONT (check marked)
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.
  MACOSX_RPATH is not specified for the following targets:
   sfgui
This warning is for project developers.  Use -Wno-dev to suppress it.

Generating Done
Opened Terminal on Mac -> Found Build File -> Typed "Make -j4" ->2 Errors
[ 84%] Linking CXX executable Layout
[ 84%] Built target Layout
Scanning dependencies of target ProgressBar
[ 85%] Building CXX object examples/CMakeFiles/ProgressBar.dir/ProgressBar.cpp.o
/Users/blankblank/Desktop/SFGUI-master/examples/OpenGL.cpp:63:29: error: no
      member named 'tan' in namespace 'std'
        auto frustum_height = std::tan( fov / 360 * pi ) * near_distance;
                              ~~~~~^
[ 85%] Linking CXX executable Notebook
1 error generated.
make[2]: *** [examples/CMakeFiles/OpenGL.dir/OpenGL.cpp.o] Error 1
make[1]: *** [examples/CMakeFiles/OpenGL.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 86%] Linking CXX executable Multiview
[ 86%] Built target Notebook
[ 86%] Built target Multiview
[ 87%] Linking CXX executable ProgressBar
[ 87%] Built target ProgressBar
make: *** [all] Error 2

Test
I also built for X-code in c-make and got OpenGL error upon compiling inside x-code
Title: Re: SFGUI (0.3.0 released)
Post by: eXpl0it3r on August 05, 2015, 10:33:24 am
Guess it's missing an #include <cmath> in the OpenGL example (https://github.com/TankOs/SFGUI/blob/master/examples/OpenGL.cpp).
You could add it yourself and try again.
Title: Re: SFGUI (0.3.0 released)
Post by: binary1248 on August 05, 2015, 10:56:39 am
Fixed.
Title: Re: SFGUI (0.3.0 released)
Post by: subconsciousbias on August 05, 2015, 11:06:32 am
Guess it's missing an #include <cmath> in the OpenGL example (https://github.com/TankOs/SFGUI/blob/master/examples/OpenGL.cpp).
You could add it yourself and try again.


That made it compile. Thank you :)
I could run the resulting program examples through the terminal. I haven't used with X-code yet, because it's 3am, just wanted to let you know. Thanks Exploiter and Tank!

Just tested with X-Code, works! YAY! FINALLY I CAN USE GUI! I have been wanting to use this for months! lolol
Title: Re: SFGUI (0.3.0 released)
Post by: kome on September 29, 2015, 11:49:43 pm
Hi, i just installed SGUI

Everything is working ok, but i noticed a simple program in SFGUI is using constant 60% of CPU, compared to a regular SFML program that uses 20%. Any thoughts on this?

I am running the program from the IDE: VS 2013 Express
Title: Re: SFGUI (0.3.0 released)
Post by: binary1248 on September 30, 2015, 12:43:40 am
Well... maybe it has to do with the fact you are using SFGUI and SFML together as opposed to only SFML? Also, saying things like "simple program in SFGUI" and "regular SFML program" doesn't tell anybody anything. If you want to provide something for others to compare for themselves, you will have to supply the code. Nobody is going to believe you until they can test first hand.
Title: Re: SFGUI (0.3.0 released)
Post by: kome on September 30, 2015, 01:49:07 am
Well... maybe it has to do with the fact you are using SFGUI and SFML together as opposed to only SFML? Also, saying things like "simple program in SFGUI" and "regular SFML program" doesn't tell anybody anything. If you want to provide something for others to compare for themselves, you will have to supply the code. Nobody is going to believe you until they can test first hand.

I was trying some of the examples that comes in the examples directory of SFGUI. Like this one:
https://github.com/TankOs/SFGUI/blob/master/examples/HelloWorld.cpp

The SFML code of arkanoid game, can be found here:
https://github.com/SuperV1234/Tutorials/blob/master/DiveIntoC%2B%2B11/2_Arkanoid/p5.cpp

Using SFML 2.3.1 and SFGUI 0.3.0
Title: Re: SFGUI (0.3.0 released)
Post by: binary1248 on September 30, 2015, 01:58:28 am
setFramerateLimit()
Title: Re: SFGUI (0.3.0 released)
Post by: kome on September 30, 2015, 02:05:22 am
setFramerateLimit()
Thanks  :)
Title: Re: SFGUI (0.3.0 released)
Post by: Kojay on January 17, 2016, 01:34:01 am
Hi,

Now that Canvas has SetView() and GetView(), is there any chance it will also get GetDefaultView() as well as the map* functions?

It has been slightly frustrating how the sfg::Canvas has been approximating the interface of sf::RenderTarget bit by bit but not quite (breaking things when replacing one).
Title: Re: SFGUI (0.3.0 released)
Post by: binary1248 on January 18, 2016, 12:52:19 am
Is that all that is missing? I need an exhaustive shopping list before I consider this feature for addition. ;D
Title: Re: SFGUI (0.3.0 released)
Post by: eXpl0it3r on January 18, 2016, 01:55:19 am
Is it really that complex to manage yet another view? Especially given that you're already managing at least one other view. ;)
Title: Re: SFGUI (0.3.0 released)
Post by: Kojay on January 19, 2016, 01:31:58 am
Firstly, it is redundant, because I know there is a view in the canvas.
Secondly as I already remarked, if I was drawing something on a sf::RenderWindow/sf::RenderTexture and now wish to draw it on a sfg::Canvas, this requires extra work (given that I use the interface of sf::RenderTarget).

Is that all that is missing? I need an exhaustive shopping list before I consider this feature for addition. ;D


These are the differences between sf::RenderTarget and sfg::Canvas at the moment. sf::RenderTarget::getSize() seems covered by sfg::Widget::GetAllocation().
Not sure about GL states, haven't tried mixing SFML and GL drawing on a canvas.
It will be great if sfg::Canvas was indistinguishable from sf::RenderTarget. This may be quite simple now, I don't know. (I had tried this in the past and ran away scared from the internals of the Canvas).
Title: Re: SFGUI (0.3.0 released)
Post by: lordseanington on February 05, 2016, 03:28:02 am
SFGUI has been a full lifesaver to me and my projects, without it i would have terrible looking login screens and in general, thanks to SFGUI, it looks great. Please keep up the excellent work.
Title: Re: SFGUI (0.3.0 released)
Post by: Suslik on April 27, 2016, 10:41:35 pm
SFGUI crashes for me if I close console application window with its own "close" button. code is as follows:
#include <SFGUI/SFGUI.hpp>
#include <SFGUI/Widgets.hpp>

#include <SFML/Graphics.hpp>

int main()
{
  sf::RenderWindow appWindow;
  appWindow.resetGLStates();
  sfg::SFGUI sfgui;
  while (1);
  return 0;
}
 

More complicated code including standard samples crashes as well when I close console window.

It crashes somewhere in sfg::SFGUI spamming all the console with messages like these:
(https://dl.dropboxusercontent.com/u/25635148/SFGUI%20crashes.png)

With an access violation like this:
(https://dl.dropboxusercontent.com/u/25635148/SFGUI%20crash%20message.png)

I'm using Visual Studio 2015 with latest official SFML 2.3.0 x86 distribution and prebuilt SFGUI from here https://nightlybuilds.ch/project/show/5/SFGUI/

I have tested my previous setup that uses year-old(approximately) versions of both SFML and SFGUI and they both work fine without crashing.
Title: AW: SFGUI (0.3.0 released)
Post by: eXpl0it3r on April 28, 2016, 12:20:56 am
Closing the console window is not normal closing behavior. It's closer to calling the exit() function, meaning you don't get a clean application destruction, as such it's not recommended to close an SFML application via closing the console. ;)
Title: Re: SFGUI (0.3.0 released)
Post by: Erdrick on May 09, 2016, 04:35:09 am
Hi,

I'm trying to build SFGUI 0.3 using Visual Studio Community 2015 and was wondering if anyone had success doing that yet?

I was able to configure and generate using the CMake utility but then while running nmake install I got some errors.  SFML_STATIC_LIBRARIES is checked and SFGUI_BUILD_SHARED_LIBS was unchecked.

 I copied what i thought was the relevant portion below
(click to show/hide)
Title: Re: SFGUI (0.3.0 released)
Post by: eXpl0it3r on May 09, 2016, 07:08:03 am
If you have also checked SFGUI_USE_STATIC_STD_LIBS but your SFML version hasn't been built with SFML_USE_STATIC_STD_LIBS being checked, thus you get compatibility issues. Either uncheck it for SFGUI or rebuild SFML with the check active.
Title: Re: SFGUI (0.3.0 released)
Post by: Erdrick on May 13, 2016, 04:19:23 am
If you have also checked SFGUI_USE_STATIC_STD_LIBS but your SFML version hasn't been built with SFML_USE_STATIC_STD_LIBS being checked, thus you get compatibility issues. Either uncheck it for SFGUI or rebuild SFML with the check active.

Hi eXpl0it3r, thanks.  I got a couple of builds to work now after starting from scratch.  One non-static and one static build.  Both had SFGUI_BUILD_EXAMPLES and SFGUI_BUILD_DOC turned off, i'll try with that next.
Title: Re: SFGUI (0.3.0 released)
Post by: Erdrick on May 14, 2016, 05:59:07 pm
I am still stuck so I put some questions in the SFGUI forum to see if I can get some help.

http://sfgui.sfml-dev.de/forum/post2662.html#p2662
Title: Re: SFGUI (0.3.0 released)
Post by: LarsXYZ on June 16, 2016, 04:22:58 pm
I have been trying for three days now to build SFGUI for Visual Studio 2015. It just won't work. Does anyone have a version laying around they can chuck my way? It would be very much appreciated.
Title: Re: SFGUI (0.3.0 released)
Post by: fallahn on June 16, 2016, 05:18:50 pm
Does anyone have a version laying around they can chuck my way? It would be very much appreciated.

This repo (https://github.com/fallahn/CHIP8/tree/master/Chip8) has a copy in the include and lib directories.
Title: Re: SFGUI (0.3.0 released)
Post by: LarsXYZ on June 17, 2016, 12:44:30 pm
Thank you so much!  :D
Title: Re: SFGUI (0.3.1 released)
Post by: Tank on July 18, 2016, 08:14:04 am
Thanks to the continuing effort of binary1248 and other contributors, we are pleased to announce the release of version 0.3.1. That version is mainly, as the version number suggest, a bugfix release with some neat enhancements. API is compatible with 0.3.0.

Binary releases for Windows are once again available, to help getting started quicker. Thanks to eXpl0it3r for building those.

Download

Grab your copy from here (http://sfgui.sfml-dev.de/download/).

Changelog

Enhancements:
Fixes:
Title: Re: SFGUI (0.3.1 released)
Post by: shadowmouse on July 22, 2016, 10:12:04 pm
Is it possible to dynamically add labels/widgets into a box many times? I've put the code in a spoiler tab because it's 80ish lines, but it's based on the Hello World example, so I don't think it can be much cut down. Whenever I press the button, which packs another label into the box, a second time, the program crashes with Segmentation Fault (core dumped) printed to the terminal. When I run it in the Debugger, it comes up that the container::HandleEvent done by the Box which is having labels added to it crashing.
This was done with the GitHub version of sfgui from about a week ago.
(click to show/hide)
Title: Re: SFGUI (0.3.1 released)
Post by: binary1248 on July 22, 2016, 10:42:22 pm
SFGUI doesn't delay execution of your signal handlers to some arbitrary point in the future where they are "safe" to be run (many bloated GUI libraries actually do this because they think it somehow makes the library easier to use...). They are run on the spot when the associated widget determines that the corresponding event has been triggered. This means that if you alter a widget hierarchy while it is being stepped through, you will get undefined behaviour. Exactly the same as if you were iterating through a std::vector and accidentally insert an element into it in one of the functions you call within the loop.

You don't pay for what you don't use.
Title: Re: SFGUI (0.3.1 released)
Post by: shadowmouse on July 22, 2016, 10:51:25 pm
I've changed it to this, and it now works:
(click to show/hide)
This looks a bit weird, and I'll probably change the program structure so that it seems a bit more natural, but if it looks stupid and it works, it isn't stupid. Thanks for clearing this up. :)
Title: Re: SFGUI (0.3.1 released)
Post by: shadowmouse on July 28, 2016, 03:15:39 pm
This seems like a stupid question, so I held off from asking it, but I haven't made any progress. How would I make a Widget (i.e. a class that inherits from Widget and can be added to Containers, drawn by the rendering engine etc), out of other predefined Widgets? I can do it by making a class which contains a Box that contains the Widgets, and having a GetWidget() method, for adding it into Containers, however I'd much rather make a class which is an actual Widget. As a simple and arbitrary example, the sort of thing I'm trying to do is make a dropdown box out of a Label, a Button and a ScrolledWindow (that's not exactly what I'm making, but it's much easier to explain).
Title: Re: SFGUI (0.3.1 released)
Post by: binary1248 on July 28, 2016, 07:18:55 pm
https://github.com/TankOs/SFGUI/blob/master/examples/CustomWidget.cpp
Title: Re: SFGUI (0.3.1 released)
Post by: shadowmouse on July 28, 2016, 07:54:16 pm
I've seen that, my question was how to do it with predefined sfg::Widgets, rather than drawing primitives. I'm basically just talking about the InvalidateImpl() function, as I'm wanting to draw my custom widget's member Widgets, rather than creating all the shapes manually. What confused me more, is that IIRC, Box doesn't implement InvalidateImpl() and Frame only draws a rounded rectangle, so how do the children get drawn?
Title: Re: SFGUI (0.3.1 released)
Post by: binary1248 on July 28, 2016, 08:02:36 pm
Every widget takes care of all its own drawing. They can't and don't "inherit" the drawing of their superclasses. If they are invisible, InvalidateImpl() will be left empty. If you want to override an existing Widget's behaviour, override handling of all of the relevant events and drawing of the Widget.
Title: Re: SFGUI (0.3.2 released)
Post by: Tank on April 06, 2017, 03:27:41 pm
Version 0.3.2 has been released (https://github.com/TankOs/SFGUI/releases/tag/0.3.2)
Title: Re: SFGUI (0.3.2 released)
Post by: theo on April 10, 2017, 01:02:15 pm
Hello,

Is there a known problem with the SFGUI website? I asked a question on the forum, but now I can't reach it anymore. First it gave a 404 (not found), now the URL dumps me to the github site.

Thank you.
Title: Re: SFGUI (0.3.2 released)
Post by: eXpl0it3r on April 10, 2017, 01:49:28 pm
The forum and website is down for now, until Tank finishes moving them to the new server.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on April 10, 2017, 04:45:00 pm
OK thanks.
Title: Re: SFGUI (0.3.2 released)
Post by: InversePalindrome on April 18, 2017, 05:34:59 pm
Is there a way to set a background for a label, making them look similar to the background of a button?
Title: Re: SFGUI (0.3.2 released)
Post by: eXpl0it3r on April 18, 2017, 05:40:04 pm
Background as in color? Or do you mean the outline?
Title: Re: SFGUI (0.3.2 released)
Post by: InversePalindrome on April 18, 2017, 06:14:37 pm
Background as in color? Or do you mean the outline?
The outline of the label, not the text itself.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on April 24, 2017, 11:48:06 pm
I notice that the SFGUI website is still down, and since some developers read this thread, I take the liberty of asking my question here too.

The problem is as follows.

I have two spinbuttons, A and B.
Both can be changed individually by user interaction.
If I change the value of A by user interaction, the bound processing function also changes the value of B programmatically, through the SetValue function.
If I do this, button B gets two signals instead of the expected one.

Here is the code:

Quote

#include "stdafx.h"
#include <iostream>
#include "SFGUI/SFGUI.hpp"
#include "SFGUI/Widgets.hpp"
#include "SFML/Graphics.hpp"

using namespace std;

constexpr int SCREEN_WIDTH = 800;
constexpr int SCREEN_HEIGHT = 600;

class HelloWorld
{
public:
   HelloWorld () {}
   void value_changed (sfg::SpinButton::Ptr button);
   void Run ();
private:
   sfg::SFGUI sfgui;
   sfg::SpinButton::Ptr _button_a;
   sfg::SpinButton::Ptr _button_b;
};


void HelloWorld::value_changed (sfg::SpinButton::Ptr button)
{
   auto value = button->GetValue ();
   if (button == _button_a)
   {
      cout << "button A" << endl;
      _button_b->SetValue (value);
   }
   if (button == _button_b)
   {
      cout << "button B" << endl;
   }
}

void HelloWorld::Run ()
{
   sf::RenderWindow render_window (sf::VideoMode (SCREEN_WIDTH, SCREEN_HEIGHT), "Hello world");

   auto window = sfg::Window::Create ();
   window->SetTitle ("Test spinbuttons");

   auto table = sfg::Table::Create ();
   auto fill = sfg::Table::AttachOption::FILL;
   auto padding = sf::Vector2f (10.0f, 2.0f);

   auto label_a = sfg::Label::Create();
   label_a->SetText ("A");
   table->Attach (label_a, sf::Rect<sf::Uint32> (0, 0, 1, 1), fill, fill, padding);

   auto button_a = sfg::SpinButton::Create (1.0f, 10.0f, 1.0f);
   _button_a = button_a;
   button_a->SetValue (5.0f);
   button_a->GetSignal (sfg::SpinButton::OnValueChanged).Connect ([=](){value_changed (button_a); });
   button_a->SetRequisition (sf::Vector2f (60.0f, 0.0f));
   table->Attach (button_a, sf::Rect<sf::Uint32> (1, 0, 1, 1), fill, fill, padding);

   auto label_b = sfg::Label::Create ();
   label_b->SetText ("B");
   table->Attach (label_b, sf::Rect<sf::Uint32> (0, 1, 1, 1), fill, fill, padding);

   auto button_b = sfg::SpinButton::Create (1.0f, 10.0f, 1.0f);
   button_b->SetValue (5.0f);
   _button_b = button_b;
   button_b->SetRequisition (sf::Vector2f (60.0f, 0.0f));
   button_b->GetSignal (sfg::SpinButton::OnValueChanged).Connect ([=](){value_changed (button_b); });
   table->Attach (button_b, sf::Rect<sf::Uint32> (1, 1, 1, 1), fill, fill, padding);

   window->Add (table);
   sfg::Desktop desktop;
   desktop.Add (window);

   render_window.resetGLStates ();

   sf::Event event;
   sf::Clock clock;
   while (render_window.isOpen ())
   {
      while (render_window.pollEvent (event))
      {
         desktop.HandleEvent (event);
         if (event.type == sf::Event::Closed)
         {
            render_window.close ();
         }
      }
      desktop.Update (clock.restart ().asSeconds ());
      render_window.clear ();
      sfgui.Display (render_window);
      render_window.display ();
   }
}

int main ()
{
   HelloWorld hello_world;
   hello_world.Run ();
   return 0;
}


Now, if I click the up-button of spinbutton B, I get the expected output:

Quote
button B

But, if I click the up-button of spinbutton A, I get two signals on b:

Quote
button A
button B
button B

This is a problem, because I want to ignore signals originating from programmatical change of the value of B, while still handling the signals originating from user interaction with B.

It gets even stranger if I first click A, then B, en then A again. In this case the output is:

Quote
button A               // click button A
button B               // SetValue on B
button B               // mysterious second signal on B
button B               // click button B
button A               // click button A
button B               // SetValue on B, no second signal!

So, the number of signals received on B seems to depend on the exact sequence of clicks: if I click A after having clicked B, I get one signal on B. If I click A while the previous click was not on B, I get two signals on B.

Probably I am making some silly mistake, and probably I am making a fool of myself by asking, but I genuinely don't see it.
Title: Re: SFGUI (0.3.2 released)
Post by: Tigre Pablito on May 17, 2017, 12:04:40 am
Hi
Isn't any possibility of being able to use SFGUI with C#.Net?
Title: Re: SFGUI (0.3.2 released)
Post by: eXpl0it3r on May 17, 2017, 01:56:48 am
Nope, it's a C++ library and while zsbzsb has once started a .NET binding (IIRC), he never finished it.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on July 19, 2017, 12:56:32 pm
No answer for my previous question?

Let me give some background: I'm trying to implement a GURPS character generator. For those unfamiliar to GURPS: it's an RPG system, with a point-buy character generation process. You buy attributes, skills etc from a given budget of character points (CP). The default level of all attributes is 10.

A peculiar feature is that buying one attribute, can give you another attribute too. So if you buy one level of Strength (ST, cost 10 CP), you also get one level of Hitpoints (HP, cost 2 CP). And you can also buy HP separately.

So, if for example you buy one ST and one HP, it will cost 10 + 2 = 12 CP. The end result will be ST 11 and HP 12 (one HP for free from ST, and one from HP).

In my mind, the obvious way to implement that is as given in the code in my previous posting in this thread, with two spinbuttons (ST en HP), where interactively changing ST will programmatically change HP too. Problem is, that the behaviour when programmatically changing the value of the second spinbutton can give one or two signals, depending on the order of clicking. The behaviour seems to be deterministic, so it is possible to code around it. The code will have to remember the previous click too. But that will be kind of convoluted and before I go into that, I would like to know if this behaviour is intended (and if so, what is the logic behind it) or a bug.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on July 19, 2017, 01:30:53 pm
In the meantime I have been doing something else, and run into another problem.

I'm trying to make a wizard-like sequence of GUI screens. You fill in one screen, click "next" and get the next screen. I use the approach described here (https://github.com/SFML/SFML/wiki/Tutorial%3A-Manage-different-Screens) for going from screen to screen.

The problem I observe, is that when I go from screen 1 to screen 2, I see both screens through each other, transparent-like. What I suspect is happening is that both screens have their own sfg::Window object and both are being displayed. The transparancy can be due to the style chosen. My time for this project is little and fragmented (really lost moments), so I have not been able yet to experiment exhaustively.

My question is, what is the best approach for doing what I attempt to do.
- use one sfg::Window and one sfg::Desktop and propagate them through all screens of the wizard. I guess I will have to remove all widgets from the sfg::Window object when going to the next screen. Since RemoveAll doesn't seem to be recursive, this means I will have to keep pointers to all containers, and clean them in the right order.
- at the end of each screen close the sfg::Window and the sfg::Desktop and open new ones in the next screen. Since I still have the SFML RenderTarget, the application window should survive this (does it?). This way, I won't have to traverse the widget hierarchy, but I do get the overhead of opening new sfg::Window and sfg::Desktop objects for each screen.

Another question: is there any hope that the SFGUI website will be back in the forseeable future? Now there is no documentation at all on using themes. On the website there was not much, but at least there was something. Also the forum dedicated to SFGUI was nice and instructive.

I am not an experienced GUI developer. I am a programmer, but normally I do backend stuff. So maybe I miss some insight on how these things are normally done.
Title: Re: SFGUI (0.3.2 released)
Post by: eXpl0it3r on July 19, 2017, 10:11:30 pm
I haven't fully followed your posted code, but from your description, the better way to implement this, and a way that should somewhat fix your problem, is to separate the UI and the stats value. Meaning that the stats shouldn't be determined based on what is shown on the UI, but that the UI updates based on the values held by some class/struct.
So if you want to change multiple values, you just update the stats class value and then update the affected UI elements (or just all UI elements). If a UI refresh happens multiple times then that's not really an issue, as a refresh doesn't change the values.

If your problem however is due to a bug, then that should of course be fixed.
Title: Re: SFGUI (0.3.2 released)
Post by: eXpl0it3r on July 19, 2017, 10:17:37 pm
As for your second problem, it depends a bit how you want to use things. Since SFGUI unfortunately uses a lot of shared_ptr, thus as long as you have a reference to one element it will stay alive.
So if screen A and screen B each have their own window, both are instantiated and you both register them with SFGUI, they both will be drawn.
As for desktops, not sure if multiple ones make sense.

I'll poke Tank to hurry up with moving the website. ;)
Title: Re: SFGUI (0.3.2 released)
Post by: theo on July 21, 2017, 12:00:33 pm
Thanks for your responses.

First question: yes, that sounds like a good idea. I got another idea too: split the value of attributes into subvalues: base, bought, bonus. Only "bought" is a spinbutton, the others are regular labels. If the user buys ST, it increases the "bought" subvalue of ST and the "bonus" subvalue of HP. In this system, the values of the interactive widgets don't have to be changed programmatically. And also, the accounting of CP becomes easier. Cost has to be computed only for "bought" attribute points. That makes it both easier for the program to recalculate all values, and for the user to keep track of where his CP budget goes to. It also makes it easier to keep track of free (temporary) bonuses caused by spells, magic items etc. They al go to "bonus" and that way they are not included in calculating the CP cost.

Second question: yes I keep member variables pointing to widgets, so they are easily accessible from the callback functions. Those references will prevent the widgets from being destroyed. That will probably be the reason why they stay visible. This is easily fixed by setting the member variables to nullptr when the widget is no longer needed.

Also for this I have thought up a slightly different approach. The different screen objects stay alive in the screen manager object. I guess it is more efficient to just keep the windows intact, but only make the active screen visible and sensitive. That way it's easy to make a back button that keeps the choices the user made beforehand: just switch the visibility and sensitivity.
So it will work like this:
- the screen manager keeps the SFGUI and desktop objects, they are passed by reference to each screen object in the run () function. Don't want the compiler to copy them. So the run function has three parameters, all references: the SFML rendertarget, sfg::SFGUI and sfg::Desktop.
- each screen has its own sfg::Window object. The GUI layout (the widget hierarchy) is build up in the constructor of the screen object.
- if run () is called by the manager, make the current sfg::Window active: guiwindow -> SetState (sfg::Widget::State::NORMAL); and guiwindow -> Show (true);
- if "next" or "back" button is clicked, just make the current window inactive and invisible: guiwindow -> SetState (sfg::Widget::State::INSENSITIVE); and guiwindow -> Show (false);. Now the manager will call the run () of the appropriate next window. Will making the window INSENSITIVE also make all underlying widgets INSENSITIVE? Otherwise there may remain invisible hot zones on the screen, which is not what I want.
- if the wizard is left altogether, reset all widgets to default value, so the next time the user has a clean start.

Does this approach make sense?
Title: Re: SFGUI (0.3.2 released)
Post by: Sk Landry on July 21, 2017, 04:08:54 pm
Hi Theo !, i've done a program that use several windows with SFGUI (check out the video), if it's what you want, i may help you. I've done the program long time ago, so i'll need some time to check out the source code and review how i've done it.

http://www.youtube.com/watch?v=5lLBJIc7e8g
Title: Re: SFGUI (0.3.2 released)
Post by: Sk Landry on July 24, 2017, 01:08:20 am
Hi there! the method i've used for my program is the following : when i go to one screen to another, i destroy the current screen and create the next. So there is always only one screen in the program. Most of the data is stored in a SQLite database, each time a screen is created the data may be load from there.

Since screens are created at each transition, you may notice that the transition take several seconds.

Concretely i use two classes.

each time a screen is created (at each transition) i reinitialize the SFML Window GL state, the SFGUI SFGUI instance and the SFGUI Desktop instance

Quote
context.window->resetGLStates();
context.sfgui = &mSfgui;
context.desktop->RemoveAll();
Title: Re: SFGUI (0.3.2 released)
Post by: Parsley on July 25, 2017, 09:08:26 am
Hi,

I'm having trouble figuring out how to show/hide multiple sfg::Desktop in the same sf::RenderWindow. Is it possible in the current version of SFGUI? Here is a modified version of the sfgui desktop example, where I have put the second sfg::Window in a separate desktop:

Quote
#include <SFGUI/SFGUI.hpp>
#include <SFGUI/Widgets.hpp>

#include <SFML/Graphics.hpp>
#include <sstream>

class DesktopExample {
   public:
      DesktopExample();

      void Run();

   private:
      static const unsigned int SCREEN_WIDTH;
      static const unsigned int SCREEN_HEIGHT;

      void OnCreateWindowClick();
      void OnDestroyWindowClick();
      void OnFrontClick();

      // Create an SFGUI. This is required before doing anything with SFGUI.
      sfg::SFGUI m_sfgui;

      sfg::Desktop m_desktop;
      sfg::Desktop m_desktop2;
      sfg::Window::Ptr m_window;
      unsigned int m_count;

      bool m_is_second;
};

const unsigned int DesktopExample::SCREEN_WIDTH = 800;
const unsigned int DesktopExample::SCREEN_HEIGHT = 600;

int main() {
   DesktopExample app;
   app.Run();

   return 0;
}

DesktopExample::DesktopExample() :
   m_desktop(),
   m_desktop2(),
   m_window( sfg::Window::Create() ),
   m_count( 0 ),
   m_is_second(false)
{
}

void DesktopExample::Run() {
   sf::RenderWindow render_window( sf::VideoMode( SCREEN_WIDTH, SCREEN_HEIGHT ), "SFGUI Desktop Example" );
   sf::Event event;

   // We have to do this because we don't use SFML to draw.
   render_window.resetGLStates();

   // Init.
   m_desktop.SetProperty( "Button#create_window", "FontSize", 18.f );

   //// Main window ////
   // Widgets.
   m_window->SetTitle( "SFGUI Desktop Example" );

   auto intro_label = sfg::Label::Create( "Click on \"Create window\" to create any number of new windows." );
   auto create_window_button = sfg::Button::Create( "Create window" );
   create_window_button->SetId( "create_window" );

   // Layout.
   auto main_box = sfg::Box::Create( sfg::Box::Orientation::VERTICAL, 5.f );
   main_box->Pack( intro_label, false );
   main_box->Pack( create_window_button, false );

   m_window->Add( main_box );
   m_desktop.Add( m_window );

   // Signals.
   create_window_button->GetSignal( sfg::Widget::OnLeftClick ).Connect( std::bind( &DesktopExample::OnCreateWindowClick, this ) );

   while( render_window.isOpen() ) {
      while( render_window.pollEvent( event ) ) {
         if(
            (event.type == sf::Event::Closed) ||
            (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
         ) {
            render_window.close();
         }
         else {
                if(m_is_second){
                    m_desktop2.HandleEvent( event );
                }
                else
                {
                    m_desktop.HandleEvent( event );
                }

         }
      }

      m_desktop2.Update( 0.f );
      m_desktop.Update( 0.f );

      render_window.clear();
      m_sfgui.Display( render_window );
      render_window.display();
   }
}

void DesktopExample::OnCreateWindowClick() {
   ++m_count;

   m_is_second = true;

   // Create a new window.
   auto window = sfg::Window::Create();

   std::stringstream sstr;
   sstr << "A new window (" << m_count << ")";
   window->SetTitle( sstr.str() );

   // Widgets.
   auto destroy_button = sfg::Button::Create( "Destroy" );
   auto front_button = sfg::Button::Create( "Main window to front" );

   // Layout.
   auto box = sfg::Box::Create( sfg::Box::Orientation::VERTICAL, 5.f );
   box->Pack( sfg::Label::Create( "This is a newly created window, from runtime, interactively." ), false );
   box->Pack( sfg::Label::Create( "You can move me around, try it!" ), false );
   box->Pack( sfg::Label::Create( "Or click the button below to destroy me. :-(" ), false );
   box->Pack( destroy_button, false );
   box->Pack( front_button, false );

   window->Add( box );
   m_desktop2.Add( window );

   // Signals.
   destroy_button->GetSignal( sfg::Widget::OnLeftClick ).Connect( std::bind( &DesktopExample::OnDestroyWindowClick, this ) );
   front_button->GetSignal( sfg::Widget::OnLeftClick ).Connect( std::bind( &DesktopExample::OnFrontClick, this ) );
}

void DesktopExample::OnDestroyWindowClick() {
    m_is_second = false;
   // Obtain parent window.
   auto widget = sfg::Context::Get().GetActiveWidget();

   while( widget->GetName() != "Window" ) {
      widget = widget->GetParent();
   }

   // Remove window from desktop.
   m_desktop2.Remove( widget );
}

void DesktopExample::OnFrontClick() {
   m_desktop.BringToFront( m_window );
}

As you can see, I can make it so the first desktop is not interact-able when the second window is created in the second desktop by using:

Quote
                if(m_is_second){
                    m_desktop2.HandleEvent( event );
                }
                else
                {
                    m_desktop.HandleEvent( event );
                }

But the "SFGUI Desktop Example" window (contained in the first desktop) is still visible. Is there a way to hide the first desktop?

I know I can use hide/show on the sfg::Window, but is there a way to hide/show the desktop itself? I don't want to RemoveAll() the widgets from the first desktop either, as in my app the second desktop is an in-game menu. So the player would briefly visit this second desktop and then quickly return to the first desktop in its current state.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on July 26, 2017, 05:03:11 pm
Hi Landry,

I have solved the problem by keeping all window objects, and just switching the sensitive/visible states. It works perfectly. Making the window insensitive, makes all widgets in the window insensitive, so there is no weird behaviour at all.

I pushed the responsibility of switching state into the manager. So the manager keeps track of the previous window and the next one. Prev is set equal to next at the top of the loop. Next is made active (sensitive and visible). Now the screen is run, the return value is captured in next. Prev is made inactive and the loop repeats. Easy peasy.

The good thing is, that all windows are present in the manager, so switching is really fast. I guess this will turn into a bad thing if there are many windows, or the windows become big in memory footprint. But for a simple wizard, it's perfect. Also, if the user uses the "back" navigation key, he gets the previous screen exactly as he left it. No need to retype text entries, or to reselect many options.

I also base the window layout on configuration in a SQLite database, but that is not  supposed to be dynamic, so not reloading it is not a problem.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on July 26, 2017, 05:04:36 pm
@eXpl0it3r

Thanks a lot for your replies, it has been really helpful. I just needed a lightbulb moment and you have provided that.
Title: Re: SFGUI (0.3.2 released)
Post by: theo on July 27, 2017, 03:41:11 pm
@Parsley:

I don't think that using more than one desktop in SFGUI will work. See the second reply of eXpl0it3r to me:

Quote
As for desktops, not sure if multiple ones make sense.

I guess there are several basic approaches for traversing from one SFGUI screen to the next:

- keep all screens in memory and make sure only one is visible and sensitive at any given time (my approach)
- keep one window and on a navigation event empty it with RemoveAll and fill it again with the widget hierarchy of the next logical screen: you effectively reuse the sfg::Window object.
- on a navigation event destroy the sfg::Window and construct the sfg::Window of the next screen (Landry's approach)

What works best for your situation depends on your project: if the screens are lightweight (no big background graphics etc) and static, my approach works well. If the layout of the screens is dynamic and can be different every time depending on data, or the screens have a big memory footprint,  Landry's approach will work well.

I don't know how expensive destroying and reconstructing sfg::Window objects is. I don't expect that to be a dealbreaker, but if screen transitions become slow, it's probably worth the effort to try reusing it.

Note: I'm not an SFGUI developer, so take my remarks for what they're worth.
Title: Re: SFGUI (0.3.2 released)
Post by: Parsley on July 27, 2017, 04:28:05 pm
Hi Theo,

Thanks for your suggestions. My problem is that in my app I'm trying to keep the first desktop in its current state (of which windows are showing and which are hidden) while the user is interacting with the second desktop. Then when the user is done with the second desktop, they can go back to the first desktop with only the windows they already had open showing (I have about 30-40 windows in the first desktop - it's a big program).

I'm experimenting with adding something like below to desktop.hpp, but it's not quite working yet:

Quote
      WidgetsList m_hidden;

      void HideDesktop(){
            WidgetsList::iterator itD = m_children.begin();
            while(itD != m_children.end()){
                if((*itD)->IsGloballyVisible()){ //if currently visible, hide it
                    m_hidden.push_back(*itD);
                    (*itD)->Show(false);
                }

                ++itD;
            }
      }

      void ShowDesktop(){
            WidgetsList::iterator itD = m_children.begin();
            while(itD != m_children.end()){
                WidgetsList::iterator itW = m_hidden.begin();
                while(itW != m_hidden.end()){
                    if(*itD == *itW){ //If found in hidden list
                        (*itD)->Show(true);
                    }
                }

                ++itD;
            }
            m_hidden.clear(); //All showing so none should be hidden
      }

Title: Re: SFGUI (0.3.2 released)
Post by: Parsley on July 29, 2017, 02:08:31 pm
Ok I found another way of doing what I wanted. I keep a vector of all the windows I've created in the main desktop, and when I go to look at the second desktop I hide all the visible windows and store the ones I've hidden in a separate list. Then when it's time to unhide them, I go through that list and call Show(true):

Quote
        std::vector<sfg::Window::Ptr> m_allWindows;
        std::vector<sfg::Window::Ptr> m_hiddenWindows; //For storing which ones were visible

void HideAllVisibleWindows()
{
    std::vector<sfg::Window::Ptr>::iterator itW = m_allWindows.begin();
    while(itW != m_allWindows.end())
    {
        if((*itW)->IsGloballyVisible())
        {
            (*itW)->Show(false);
            m_hiddenWindows.push_back(*itW);
        }

        ++itW;
    }
}

void ShowAllVisibleWindows()
{
    std::vector<sfg::Window::Ptr>::iterator itW = m_hiddenWindows.begin();
    while(itW != m_hiddenWindows.end())
    {
        (*itW)->Show(true);

        ++itW;
    }
    m_hiddenWindows.clear();
}

Title: Re: SFGUI (0.3.2 released)
Post by: Dehaku on October 19, 2017, 05:29:38 am
Spent the past few hours digging, couldn't find it.
How do you change the color of the titlebar in windows and such?
Best I can do is backgrounds, borders, and highlights with SetProperty() on GetEngine()
If there's a list of widget properties I could look that, that would be immensely helpful and appreciated.

Edit: Label properties would be useful too, for changing their text color specifically.
Title: Re: SFGUI (0.3.2 released)
Post by: Parsley on October 19, 2017, 12:33:12 pm
There used to be a reference page for widget properties but it's disappeared since they took the old website down. For the window titlebar the property is called 'TitleBackgroundColor'. Label text color I *think* the property is just called 'Color'.
Title: Re: SFGUI (0.3.2 released)
Post by: FRex on October 19, 2017, 01:13:04 pm
Yes, see (some properties that affect sizes like font name, font size, etc. are in widget cpp files but most are in BREW cpp files that implement turning widgets into render lists or what not):
https://github.com/TankOs/SFGUI/blob/master/src/SFGUI/Engines/BREW/Window.cpp#L16
https://github.com/TankOs/SFGUI/blob/master/src/SFGUI/Engines/BREW/Label.cpp#L15
Title: Re: SFGUI (0.3.2 released)
Post by: binary1248 on October 19, 2017, 04:58:46 pm
The defaults are all here: https://github.com/TankOs/SFGUI/blob/master/src/SFGUI/Engines/BREW.cpp#L15
Title: Re: SFGUI (0.3.2 released)
Post by: Dehaku on October 20, 2017, 08:24:05 pm
Beautiful, Thanks for all the help!
Much appreciated.
Title: Re: SFGUI (0.4.0 released)
Post by: Tank on October 29, 2018, 10:13:52 am
0.4.0 is out :-) (https://github.com/TankOs/SFGUI/releases/tag/0.4.0) Binaries for Windows people will follow shortly.

This is mainly a maintenance release, however it also includes a larger change regarding the CMake config. Please report any issues you get at GitHub, thank you.

Enhancements


Fixes


Downloads (https://github.com/TankOs/SFGUI/releases/tag/0.4.0)
Title: Re: SFGUI (0.4.0 released)
Post by: conleec on August 30, 2019, 03:12:04 am
Hello everybody,

Full disclosure: I'm a complete nube, and am trying to learn SFML and SFGUI. Unfortunately, I cannot get SFGUI to build under Max OS X 10.12.6. I get an error that the CoreFoundation.framework cannot be found. Is there an updated build tutorial that addresses this apparent change in OS X structure?

I actually found CoreFoundation.framework in the XCODE devs folder, trying to direct CMAKE to look there, didn't work for me either.

Any help would be GREATLY appreciated, as I'd love to use this GUI library as I continue to learn C++ and SFML.

Chris Conlee

(https://photos.google.com/photo/AF1QipNoz5dPt0W8k2hVZhkkSumxsrGN99SqkZzD6HOZ)
Title: Re: SFGUI (0.4.0 released)
Post by: binary1248 on August 30, 2019, 10:41:40 pm
I'm not a macOS expert, so no idea what that error even means.

You could try building and linking SFGUI statically. That way the system libraries that you need to link into your final application will be covered either by SFML or your own project.
Title: Re: SFGUI (0.4.0 released)
Post by: conleec on August 31, 2019, 07:21:07 am
Is there any way you can give more details on building this library statically? I did what I thought was necessary, but got the same error. Is CoreFoundation.framework required for this library? It doesn't seem to be a part of OS X anymore.

Can anybody else build it with a Mac running 10.12 or greater and let me know if it works for them?

Chris
Title: Re: SFGUI (0.4.0 released)
Post by: fallahn on August 31, 2019, 11:11:18 am
I can confirm the same CMake error when configuring on 10.14.6. I can't say *why*, because macOS isn'y my main platform, but removing the relevant parts in the CMakeLists.txt (commenting out lines 108-121) let me make/install SFGUI and build/run the examples. (Note I used make files however, not xcode project files, if that makes a difference)
Title: Re: SFGUI (0.4.0 released)
Post by: conleec on August 31, 2019, 09:49:05 pm
I can confirm the same CMake error when configuring on 10.14.6. I can't say *why*, because macOS isn'y my main platform, but removing the relevant parts in the CMakeLists.txt (commenting out lines 108-121) let me make/install SFGUI and build/run the examples. (Note I used make files however, not xcode project files, if that makes a difference)

Thank you fallahn! That was going to be my next attempt. It seems like CoreFoundation is no longer a part of Mac OS X, so I was wondering if it would work to simply remove it from the equation.

I'm actually quite new with C++ and especially SFML (learning concurrently), so it's ALL hit and miss for me. I'm not a TOTAL neophyte; I studied computer systems engineering in 1985, but C++ wasn't really part of the curriculum. Spent some time with C. But most of my lab time was Fortran and Cobol, believe it or not. Then life got in the way, and I went in a completely different direction. Glad to be getting back into it. But the brave world of OOP is taking some time to get my head around. :)

Oh, and yes, I'm ALSO using unix makefiles...

Chris
Title: Re: SFGUI (0.4.0 released)
Post by: conleec on September 01, 2019, 09:48:04 am
Awesome news...sort of.

I got the library to build finally and it runs the samples. BUT, it throws a ton of errors about deprecated OpenGl calls in OS X Mojave. I found this, which seems to confirm the issue..

https://stackoverflow.com/questions/52509427/mac-mojave-opengl (https://stackoverflow.com/questions/52509427/mac-mojave-opengl)

In any event, it works for now and I am learning tons.

One question though. I'm running a MacBook Pro with Retina display and the samples are TINY!!!! Is there a compiler setting or a setting in the code that will scale for high density displays?

Thanks in advance.

Chris Conlee