Hi
After this discussion, I've decided to open the development of SFML to a team composed of the most talented and involved developers in this community (sorry for those I forgot -- the team may grow in the future).
What this means is that I'll no longer be the only one to decide and write code; this was already the case with Nexus, Marco and Jonathan being part of the team, but this was just enough to make SFML survive. These new members (yes, the list is coming) will bring their motivation, ideas and technical skills, and there will be nobody to say "no" to what they propose. Instead, the team will discuss every suggestion and implement it if it meets an agreement.
Development of bug fixes and new features will also be a lot more open to the community, we don't want motivated members to see their contribution rejected most of the time. We need everyone's energy to make SFML the best multimedia library out there.
That's a good idea because your concurrant (SDL) is really taking advance.
I've tested (and not only me) several applis with SDL and SFML on different plateforms.
SDL is able to display a window on any system (even on a raspberry pi) with every driver and even with old architectures.
This is not the case of SFML, because of several reasons :
-SFML is using XrandR, the video modes fails to load with Xinemara on linux.
-All extensions of openglES are not always present in the drivers, opengl just get the adress of the functions defined in the driver but if the adress is not present there's a link error, maybe it's due to the missing of glew with opengles.
SDL seems to create the opengl context without any problems, most of all, SDL is opensource so you should take a look into the code. (At least for the dependencies and for the opengl context)
