SFGUI (0.4.0 released)

[asdatapel]

lol I thought you were using a theme on Windows, and the theme looked goog, so I asked what it was

[Tank]

UPDATE

• ToggleButton and CheckButton added.
• 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, so Boost.Spirit has also been dropped as an dependency for the theme parser. It should be applied to master in 1-2 days.
  

[Laurent]

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

[binary1248]

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 Nice of you to take care of the (possibly) worrying users though ^^.

[Tank]

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.

[Groogy]

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?

[deadalnix]

You'll find classes Thread, Mutex and Lock in the module system.

[Tank]

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.

[Groogy]

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?

[Tank]

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.

[Groogy]

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.

[Tank]

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

[Naufr4g0]

I updgraded sfgui libraries and I linked them to my project, but the size of my button changed. Why?



How can I resize buttons manually?
They are inside a sfg::box.

[Tank]

Can you show the relevant code please?

[Naufr4g0]

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