Paths that take wstring (e.g. for LoadFromFile/SaveToFile)

[nitram_cero]

Needed for files with Unicode characters (e.g. Open a filename in russian, japanese, chinese, etc.)

I'm making an application with SFML+wxWidgets and images will be loaded depending on user input. I can't know beforehand the filenames nor change them.
For now I just copy the image file to an ANSI path (duplicate the file), load it, and delete it... but this is no solution.

I think someone else already asked for this. Sorry if it's repeated, I searched the forum but I don't seem to find it.

Thanks
-Martín

[Laurent]

Yep, someone already asked

And it's part of the new DataStream framework which is in the roadmap for SFML 2.0.

[nitram_cero]

I figured out that could load each file entirely to RAM with standard functions and just load them from there.

This, of course, wouldn't be possible when streaming songs via sf::Music. It would beat the whole point.

Are you abandoning SFML 1.x interface upgrades?
Because I'm cool with having a super-duper SFML2.0, but waiting for it to be stable doesn't solve the lack of key functionality present in SFML1.x.

Of course I don't know how many users it has, as most are not probably actively posting here  :lol:

This is a big interface flaw and, in my opinion, should be adressed in SFML1.x instead of just pushing it with everything else to SFML2.0

* Replacing each string parameter in Load/Save functions with a new sf::filename class that takes either a string or wstring implicitly thru it's constructor could be an easy way of fixing it.
(Converting from string to wstring (ansi to unicode) is locale-charset dependent, so it should be avoided.)

* Loading to RAM and calling LoadFromMemory for unicode strings (except for Music objects) could be a quick way of implementing a new interface.


Best regards
-Martín

[Laurent]

Are you abandoning SFML 1.x interface upgrades?

Absolutely. Every modification to the public interface will now happen in the SFML 2.0 branch. I want to make the SFML 1.x branch stable before switching to the new version, so that I can concentrate on SFML 2.0 and stop maintaining SFML 1.x quickly rather than maintaining both for a very long time.
I really want to make SFML 2.0 the next version; it's not like SDL 1.3, don't worry

[nitram_cero]

Ok. I don't share that point of view but I have to accept it.

It's probably that I'm used to the way wxWidgets development works.
New, radical changes are made to the new version, but necesary ones are put in both the stable and new branches.

Regards
-Martín