Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFGUI (0.4.0 released)  (Read 391554 times)

0 Members and 8 Guests are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFGUI
« Reply #15 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?
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #16 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:

  • .fancy -> applies to ALL widget types with ANY ID in ALL states, but with class "fancy"
  • Button:Prelight -> applies to buttons with ANY ID, ANY class, but state "Prelight"
  • #inventory -> applies to ALL widget types with ANY class in ANY state, but with ID "inventory".


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.

victorlevasseur

  • Full Member
  • ***
  • Posts: 206
    • View Profile
SFGUI
« Reply #17 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|

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #18 on: October 20, 2011, 07:19:55 pm »
What compiler are you using?

victorlevasseur

  • Full Member
  • ***
  • Posts: 206
    • View Profile
SFGUI
« Reply #19 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:

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #20 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.

victorlevasseur

  • Full Member
  • ***
  • Posts: 206
    • View Profile
SFGUI
« Reply #21 on: October 20, 2011, 09:28:31 pm »
Thanks, I use Boost 1.46.1 for information.
But, SFGUI compiles and functions correctly.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #22 on: October 20, 2011, 10:52:15 pm »
Same Boost version over here. Are you on a Linux system?

victorlevasseur

  • Full Member
  • ***
  • Posts: 206
    • View Profile
SFGUI
« Reply #23 on: October 21, 2011, 07:06:09 am »
No, I compile on a Windows system.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #24 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.

victorlevasseur

  • Full Member
  • ***
  • Posts: 206
    • View Profile
SFGUI
« Reply #25 on: October 26, 2011, 08:36:59 pm »
Is multi-character selection planned for sfg::Entry ?

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #26 on: October 27, 2011, 09:52:37 am »
Not yet, may change in the future, but I think not for a first release.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #27 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.

Benefits are:
  • Compiling is incredible fast again. ;) (before, compiling one translation unit took about 1.4-1.8 seconds on a 3 GHz quadcore system).
  • One less (Boost) dependency.
  • Easier usage because the code is fitted for SFGUI.

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).

Naufr4g0

  • Full Member
  • ***
  • Posts: 112
    • View Profile
SFGUI
« Reply #28 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. :)

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
SFGUI
« Reply #29 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).