One other point I can think of is your code lacks some comments. You put some but not enough to my mind. It makes your code a bit tricky to understand sometimes.
I put comments everywhere I had the feeling of "Okay, this can be confusing when being read in the future again". Of course other people have different feelings and didn't write the code (thus having another understanding). I'll try to keep the level up.
This is useful especially if you don't want to have to maintain SFGUI for the remaining years of your life *joke*. More seriously, it would allow people to help you more easily (and notice the bad points faster btw).
And.. you already know what I told you about delegating the widget serialization/deserialization in the concerned widget's code instead of doing so in the widget factory
I don't like this idea much, since widgets shouldn't be concerned with any type of serialization. That's the task of other instances. Also this would eliminate the possibility to exchange the serialization driver (or would make it at least at lot more painful to implement/increase complexity).
Do you mean changing the way the widgets are (de)serialized ?
If I'm right.. then you should just use an abstraction layer (baaaaaah *abstraction is evil* *gets out*). Okay that's still more work (I could work on it myself), but that would fix this point.
The other reason is... imagine you have several people working on 3-4 different new widgets. Is it easier to work on the same factory widget or working only on ones part ?
(especially because the widget factory would become bigger and bigger as you add widgets and probably harder to maintain).
That's something where you can't do anything against it. If you put the serialization code into the single classes, it's still there, no matter if it's inside the widget's class or a big factory class. The advantage is however that the code is completely separated, which makes it indeed better to maintain.
Yes you can !! *reminds me of something..*
As you say "The advantage is however that the code is completely separated, which makes it indeed better to maintain." : that's exactly what I wanted to point out. You cannot prevent the library from growing, but you can prevent developers from having to work on big factories => don't care about what have been done before and just focus on one thing.
One thing you could do is splitting up your custom factory code into more classes and register each via sfg::GUI::RegisterFactory(). You can even create one factory class for each custom widget *and* put the deserialization code into the widget's class if you like that approach. 
And you get closer and closer by the idea of registering each class to be able to use a standardized (de)serialization process
. The idea is.. as soon as a class implements the “serializable” interface, it'll be registered in the SFGUI runtime handler/global widget factory/whatever you want (let's call it Lily). And as soon as it is registered, the YAML loader (or any other format loader) knows it can look for Lily and ask her to (de)serialize the widget. Then Lily just has to use the provided interface to do her job.
(thank you Mindiell for the interface idea btw ^^)
The other issue with this that I can think of now... is the user forgetting to update its widget factory according to his changes to the widget. That's not much but, it'd make the things easier (and I suppose your purpose is to provide an easy-to-use library 
).
I guess that'd be a plain PEBKAC. I just like the idea to have a single instance that's responsible for deserializing widgets.
PEBKAC is everywhere ^^, and you'll need more than a "I just like the idea" to convince me :-° *gets out before getting whipped*
Edit 2: one think I thinked of too is not processing the YAML loading through the GUI class. I'd rather think of a specific YAML loader/writer class (just because it doesn't really fit the GUI class's role to my mind, and because it would ease my work (working both on the same class looks like a mess to me, especially if it's not required)).
You're right, I'll separate the YAML loading stuff from sfg::GUI. This is easily possible, because sfg::GUI's public interface provides everything that an external loader class needs.
Good points, keep it goin'!
I'll try to do so, thanks!
