Will SFML extended libraries be ever integrated as native of SFML?

[magneonx]

I just notice somehow SFML is not really for games but mainly for multimedia applications, but I see somehow that SFML has many known extended libraries like Thor or GUI functionality like SFGUI. I just wanna know will it ever be integrated in the near future? If not so, why not? Is it because SFML must maintain its general focus on wide range multimedia applications? I am just curious.

Thank you!

[eXpl0it3r]

No, SFML won't adapt such libraries (except most likely some ideas from SFNUL for SFML 3.0).

SFML's goal (as I understand it) is to provide a easy, yet powerful API that is should be rather low level. SFML should not turn into a framework or even worse an engine, it simply provides functionality with a clean API, which one can build on top. Thor on the other hand introduces a lot of nice features, but if you look at them, they are mostly of higher levels (particle system, resource management, etc).
SFGUI on the other hand is very big step into a different direction. If you've ever tried implementing a GUI that goes beyond a few buttons, you'll very quickly learn that this is a very, very hard task. This would really explode the scope of what SFML is and should be. Besides that, SFGUI will in the near future cut-off SFML as dependency and run everything via OpenGL - No panic! It will of course still work with SFML, but also with any other application using OpenGL.

After all, there's really no reason to merge this into one library. Simply link them and be happy to use them all at once.

[Nexus]

Not only the code styles, but also the philosophies behind the libraries differ slightly. SFML intends to be beginner-friendly, and its API mostly consists of well-known C++ features (classes, some polymorphism and very few templates). Thor on the other hand sometimes requires knowledge about advanced C++11 features (smart pointers, functionals, ...) -- but once you know them, you can achieve a lot with very few code.

Furthermore, the separation of libraries has the advantage that different approaches can be used to build extensions based on core SFML. For example, some people prefer the simple AnimatedSprite from the Wiki to animate sprites, while others need the genericity and features of thor::Animator. Or you can build a simple resource manager like ResourceHolder from the SFML book, or use a quite sophisticated one conceived for a few special cases, such as thor::ResourceCache.

It would not only be a hard (and considering API stability, potentially irreversible) decision to choose one specific extension rather than the other, but it would also increase the amount of SFML code to be maintained, slowing down overall development. It's crucial that SFML provides a basic abstraction layer that hides low-level libraries and OS-specific APIs, so that other developers can build their high-level extensions on top of it.