Philosophical question: What defines what should or should not be part of sfml?

[Dbug]

I'm been looking a bit on the forum, and there's been a number of requests that have been answered by "use this other library", or "this has nothing to do in a media library".

What I'm wondering is that is the actual delimitation between what makes sense to have in such a library.

Typically I was using SDL, and SDL wraps most of what you need. I switched to sfml because the performance of SDL was abysmal and having hardware acceleration by default was nice.

Now my problem with sfml is that in the current state I can't just use sfml and be done with it. If I want to do any serious work I need for example a basic portable file system library. Obviously sfml itself is loading and saving stuff (images, shaders, sounds), so I really wonder why there's no portable sf::fileLoad / sf::fileSave in the sfml API. That would be very nice and help keep some consistent code without having to add some dependencies on boost for example.

Similarly, most "multimedia" applications have a lot of assets. Assets take a lot of room; and many small assets tend to eat disk space quite fast due to cluster size. It could be nice to have some "container" system (like in old Doom and Quake WADS, or simple ZIP/7zip/rar).

In my particular case I just wanted to have a portable way to scan a folder to get a list of save games without having to maintain on the side some index file.

So what's the official stance on this topic?

[eXpl0it3r]

For the users it's 'simple': Laurent decides what gets into SFML and what not.

From my understanding the original idea was to provide the most basic elements that should help you build your stuff on top of it. As of now the library supports actually way more than that original idea would require, e.g. a high level class as sf::Sprite isn't really something basic and can be easily done on your own.
On top of that you should stop looking for an All-In-One library, because does do not exist!
SFML is already quite hard to maintain, since it has many facets and if you'd add just one more this would need again many extra hours. Thus libraries get developed for specific tasks/topics on which the developer can spend all his freetime and doesn't need to care about a hundred different aspects.

Besides that, SFML has an abstract sf::InputStream class, with which give you the possibility to have a portable and independed way of loading resources (e.g. from a networks stream or a zip files etc...).

[Laurent]

As you found, and as you probably expect, the official answer is "this has nothing to do in a media library"

What's the point of mixing many unrelated topics in a single library? It's too much work, the result can't be a well-designed and robust library (unless you have a lot of time and/or many developers behind it). Libraries that focus on specific tasks are usually much better; they do one thing, and they do it well.

And why should I implement things that are already available in very good libraries? I'd probably not do a better job.

Obviously sfml itself is loading and saving stuff (images, shaders, sounds), so I really wonder why there's no portable sf::fileLoad / sf::fileSave in the sfml API

SFML loads and saves stuff, but it only uses the standard library. There's no need for a file system API, I only need file I/O, and <fstream> is all that I need for that.

Many users would like to see SFML as a framework that they can use to build any program. But SFML is not that. It's just a multimedia library. Don't be afraid to use other libraries; in fact I don't understand why people don't want to rely on multiple libraries to create their programs.

[greeniekin]

I do kind of get this. Though it is usually not that hard to add a lot of that stuff. I have actually added my own  libs to the sfml cmake build tree for some of these things. Which has made a lot of things much simpler.
Like dateTime, browsing folders, file modified times  and various 3d stuff like a 3d sfmlText.

Problem is when do you stop.

Also if I remember correctly sdl has seperate libraries to download. Like SDL_mixer and the like.
Maybe someone could make a sf::filesystem library to download separately.

Be nicer if there was an easier way to see sfml add on libraries. SDL has that page for it. I think that can be outdone. I know there is the wiki but I am not found of wiki's for some things.

A tip if you go my way is to use WinMerge when your going to update your personal tree with the latest. Makes it so easy.

[Laurent]

Be nicer if there was an easier way to see sfml add on libraries.

I understand what you mean. It would indeed be nice to have a page on the website containing a list of SFML add-ons, with direct links and up-to-date information / version. But it would be a hell to maintain, this kind of projects usually become unmaintained and deprecated or taken over quickly. So I think that the wiki is definitely the best option. Every author can maintain the entry to its add-on, upgrade an old project, etc.

[eXpl0it3r]

Maybe someone could make a sf::filesystem library to download separately.

I'm strongly against the (public) usage of the sf namespace, because if a library would get popular, new people would be very confused, since it looks like SFML would support feature XYZ, when it's the (badly maintained) library XYZ that does this.
One should keep the official and the unofficial strictly separated. This doesn't only apply to the namespace but also the building process. Just create your own library that uses SFML and write your own build script and you don't have to use WinMerge to hack the new updates again into your modified nightmare.

With git this is very easy, just add the external libraries as submodules and you can grab the latest updates quite easy and whenever you want/need without the fear of breaking anything.

But this shouldn't stop you from contributing to the wiki or in the project forum with your extensions etc.

[The Terminator]

I'm totally for the add-on thing. It would be really nice for people to upload their creations directly to an add-on section of the website IMO.

[Predator106]

Don't be afraid to use other libraries; in fact I don't understand why people don't want to rely on multiple libraries to create their programs.

for the most part, it's NIH "not implemented here syndrome", and for the other part it's the "omgz u got so many dependencies" crazy users, i think.

i don't know about you, but i use everything i can unless it doesn't suit my needs...gets my job done faster. no point in needlessly duplicating work.

[eigenbom]

As you found, and as you probably expect, the official answer is "this has nothing to do in a media library"

But this is subjective, so really should be "Laurent defines what should or should not be part of sfml". For example, when you say multimedia, I think of video, but sfml doesn't support loading video files, and nor do I want it to, but I'm just saying that 'media library' is ill-defined. Even I would say Networking doesn't fit under the 'media library' definition, but is a useful component nonetheless, just like a simple cross-platform file/directory system could be.

Many users would like to see SFML as a framework that they can use to build any program. But SFML is not that. It's just a multimedia library. Don't be afraid to use other libraries; in fact I don't understand why people don't want to rely on multiple libraries to create their programs.

I think a lot of people come to SFML because it is simple and clean, and possibly because they are also just learning how to build graphical programs, which is supported by the nice SFML tutorials and prepackaged binaries for msvc/xcode. So when these people want to do a simple task that isn't supported, suddenly they have to go and find a library to do that thing, which may require using an API which isn't simple, or even (gasp!) compiling the library, which on Windows is especially difficult to do if an msvc project isn't supplied. So I don't think its a case of "don't want to rely on multiple libraries", rather than, "have difficulty using other libraries".

In any case, I'd be interested to hear what the majority of SFML projects were, and how their requirements match up with the feature set of SFML.

[Laurent]

But this is subjective, so really should be "Laurent defines what should or should not be part of sfml"

Of course it is subjective, since I'm the only one who decides
But I try to make consistent choices, and to stick to the initial definition of what I wanted for SFML.

For example, when you say multimedia, I think of video, but sfml doesn't support loading video files

It probably would, if it was not such a hell to support (too many dependencies, too many formats).

Even I would say Networking doesn't fit under the 'media library' definition

I think it does, according to the following definition of medium: "A format for communicating or presenting information".

So I don't think its a case of "don't want to rely on multiple libraries", rather than, "have difficulty using other libraries".

Unfortunately, the world is full of such libraries. Learning how to handle them is what a programer is supposed to do if he wants to progress. You can't stay a beginner all your life

[Nexus]

I do kind of get this. Though it is usually not that hard to add a lot of that stuff.

No, having a lot of features is indeed easy. What is difficult is a clean API and well-maintained implementation, which becomes harder with increasing functionality. That is also a reason why in 2012, one and a half decade after the release of the C++ standard, there are still so many libraries that use questionable and ancient C++ style, usually under the pretext "support for old compilers". Well-designed libraries like SFML are still a rarity, and this is to a big extent a result of the fact that Laurent exactly knows the scope of the library and is quite strict with the addition of new features.

Be nicer if there was an easier way to see sfml add on libraries.

Here, I listed some projects that may be interesting.

The problem is, only a few add-on libraries are really dedicated to the community and actively developed. Many people have implemented something for their own use, and just share it, because someone might use it. But they don't support it in the long term, they abandon the project as soon as they don't use it anymore.

Like dateTime, browsing folders, file modified times

Take a look at Boost.Filesystem and Boost.DateTime.

[eigenbom]

So I don't think its a case of "don't want to rely on multiple libraries", rather than, "have difficulty using other libraries".

Unfortunately, the world is full of such libraries. Learning how to handle them is what a programer is supposed to do if he wants to progress.

I agree, I was giving my opinion to your question about "I wonder why people don't want to use other libraries...".

And there are 'programmers' and "programmers", I would love a world with libraries that have a simple api like sfml, but its not the case. Some programmers like to hack and some just want to build games without stuffing around with multiple dependencies, etc.

For instance, getting cross-platform file handling requires something like boost::filesystem, the api/documentation of which is a whole order of magnitude more complex than sfml, but its a core task for most games or multimedia apps. The same goes for cross-platform threads, but for some reason this is included in SFML whereas the former isn't.

[Sebelius]

Yes, they have declared a recipe for what can and cannot be included in sfml. This recipe "defines" sfml's content. Imagine the developers gathering for a meeting, praying to this holy recipe in order to uncover sfml's future plans. No, i'm just kidding. Tho i believe the question should be: "what/who decides", rather than "what defines".