Stability and Projectdocumentation

[Lord Delvin]

First I want to tell you, that this project is, what I ever wanted to have, as it replaces deprecated SDL and my own small Engine nearly completely.
But there remain two questions:
First is stability of the project in terms of usage and in terms of Bugfixing.
So will there be future versions until it works?(as I saw many good projects dieing on half way to completion)
And how stabil is the current release?

Second is about documentation:
Why are only some public interfaces Documented, if the whole project is under zlib licence? It would be very nice to see how these interfaces do certain things to prevent writing and doing the same task twice.

Hopefully looking at his new sfml branch
  Lord Delvin

[Laurent]

First I want to tell you, that this project is, what I ever wanted to have, as it replaces deprecated SDL and my own small Engine nearly completely.

I'm glad to hear that

So will there be future versions until it works?(as I saw many good projects dieing on half way to completion)

Of course, SFML is not going to die. Having users feedback helps me to improve it even faster and better.

And how stabil is the current release?

It looks quite stable, I don't remember of any major bug reported for SFML 1.1. But I can be wrong, so you'd better check the forum
(I know, I should keep a clear list of reported bugs and put it online... or just use the SF bug tracker)

Why are only some public interfaces Documented

All public interfaces should be documented, which ones exactly are you talking about ?
I know non-member functions are not documented (although they are in the tutorials), but this is only because I still haven't found the doxygen option to do it.

[Lord Delvin]

I know non-member functions are not documented (although they are in the tutorials), but this is only because I still haven't found the doxygen option to do it.

Afaik in doxygen with standard config you only have to write a /** **/ or /*! */ or /// or //! in front of the object you want to document, what ever it is.

What I was thinking about, was one or two classes from priv::, which were interesting in some context I forgot about :roll:

Hmm...further reading of the documentation led me to the conclusion that sf:: classes are just facades, what's nothing bad:)
So I think I understand why there are some details missing in the documentation.
Have fun!