Contributions

[Dig]

Hi

I've noticed several times that help is not needed on the core features of SFML, but I was wondering if you have a place or accept community contributions in the form of add ons etc.,

I've ditched SDL in favour of SFML as SFML is easier, in C++ instead of C and runs fast.  One small feature I used in SDL was SDL_Config a library compatible with SDL that reads and writes .ini style files in a cross platform manner.  This is not something that I've seen for SFML and something that's really useful for storing and retrieving user preferences.

I'm going to make the module for my own (closed source) project but I'd be happy to contribute this to the community under an open source license if there is any interest.

Is there a contributions section that I've missed?  While I'm not going to release my full project as open source I'm happy to release useful thing like this as and when I get them completed.

Cheers,
Nick

Edited to subscribe to replies

[Laurent]

I've noticed several times that help is not needed on the core features of SFML, but I was wondering if you have a place or accept community contributions in the form of add ons etc.,

Of course !

Right now, we don't have a place for "community add-ons" (there's still not many of them , so what you can do first is share your add-on on the forum (in "SFML projects").

In the future, I think I'll setup something for community, to share source code, documentation, tips, etc. A wiki should be a good solution.

[tgm]

heres a quite good .ini parser:
(From Irrlicht forum, but should be easy to port)
greetz

[Laurent]

Looks like you forgot the link...

[tgm]

dammit -_-
here we go:
 http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=19655

[Dig]

Cool, I'll put something together (in the next month or so) and contribute it

Cheers,
Nick

[Dig]

I've had a think about this and come up with a slight change of plan.

ini files obviously only have one level of depth and more flexible preference manager with a hierarchy of nodes and preferences might be more flexible long term and could work for storing localization strings, key maps etc etc.,

Also the information that could be saved could include some sfml specific types (such as sf::Color and sf::Key) in addition to standard int, float, string, boolean etc.,

It'll be a statically linked library with source under the same license as sfml so it can be used in any project with sfml without issue.

Question on use and etiquette do I use the sf namespace or create my own?

ie.,

Code: [Select]

sf::PreferenceManager MyPrefs;  or

Code: [Select]

prefs::PreferenceManager MyPrefs;

Cheers

Edit: Sorry about the 'MyPrefs' example, I'm not and never have been a Visual Basic programmer, honest.  :lol:

[Laurent]

I think you should use a separate namespace, so that users are not confused about what's part of SFML and what's external.

[PM]

Why not use something sfml related, but not quite the same as sfml?

I mean, all user extensions could use "sfe", "sfex" or "sfext" namespace.

Personally, I'd really like if all user extensions would follow the same naming conventions:
root namespace: sfex
sub-namespace: <extension title>

So, for preferences (or configuration), it could be "sfex::pref::" or "sfex::conf::" or "sfex::config::".

But that's just me.

[Laurent]

I don't think that would make sense. Putting everything together in a same namespace is not enough, the different classes would still not follow the same naming conventions, the same philosophy, the same quality of code, etc.

Unless everything is reviewed by someone, separate pieces of code should remain separate.

[Redien]

Unless everything is reviewed by someone, separate pieces of code should remain separate.

Why not? There are projects who already have this kind of set up. I'm sure there are plenty of people who wouldn't mind doing such reviews.

There would have to be rules and guidelines so that the code complies with a level of quality before included and endorsed on the site.

But it's up to you if you would want to allow such a thing.

[Laurent]

As I said, if there are rules and quality requirements (and someone to apply them) then it's ok for me.

Anyway it's not up to me, if you want to start such things then go ahead. I don't have to allow or disallow every external contribution, you know

[Redien]

Well I was thinking more if you wanted to allow it to be endorsed on the site, next to the SFML library. I'd imagine you wouldn't want it to be confused with the original library.

But I'm definately interested in doing such a contribution, now if a few other people are interested we could try to make something like that happen.

[Laurent]

I think the future wiki will be a perfect place for this kind of stuff