SFGUI (0.4.0 released)

[eXpl0it3r]

This seems like a mistake, but since my notebook got stolen today, I won't be able to fix it that quickly...

[FRex]

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.

[FRex]

There's a small error in the online doc:
http://sfgui.sfml-dev.de/doxygen/classsfg_1_1Widget.html#aa0f8275f53a6157112108c0944d30f54

[Tank]

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 for that, so it won't be forgotten.

[FRex]

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

[binary1248]

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

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.

[JayArby]

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

[eXpl0it3r]

They are perfectly compatible, since they are the same.
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.

[Cpl.Bator]

how can i see the shadow in the window ?
i try to play with this :

SetProperty( "Window", "ShadowDistance", 100.f );
   SetProperty( "Window", "ShadowAlpha", 255.f );

but, no visual change.
i've included sfgui directly in my test project.

[binary1248]

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.

[Cpl.Bator]

Thx

[kralo9]

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 :/

[FRex]

Are you doing desktop.Update(someclock.restart().asSeconds())? If not, maybe try it..

[kralo9]

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.

[binary1248]

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.