More fs::path inside core

[dimitre]

The idea behind this PR is to start using fs::path directly converted to c_str() to library functions like FreeImage, FreeType etc, so the native encoding of OS is further preserved.

[dimitre]

ok one more ready to review. opinions are welcome @artificiel @ofTheo

[artificiel]

lots of stuff — phew!

one small thing: in the freeimage the explicit of::filesystem::path::{w}string().c_str() is used:

#ifdef OF_OS_WINDOWS
			retValue = FreeImage_SaveU(fif, bmp, fileName.wstring().c_str(), quality);
#else
			retValue = FreeImage_Save(fif, bmp, fileName.string().c_str(), quality);
#endif

but it can be made tighter by using c_str() directly on the path; it returns a native char *.

#ifdef OF_OS_WINDOWS
			retValue = FreeImage_SaveU(fif, bmp, fileName.c_str(), quality);
#else
			retValue = FreeImage_Save(fif, bmp, fileName.c_str(), quality);
#endif

(the example here is pretty much the use case!)

[artificiel]

ha! that's a good one: plain auto uriStr = _fileName; works because anyway c_str() is called on it... uriStr is actually superfluous and fileName can be used directly in the code

[dimitre]

I've thought the same but it failed in vs here:
https://github.com/openframeworks/openFrameworks/actions/runs/7110450617/job/19356969358

[artificiel]

ah! yes if uriWindowsFilenameToUriStringA does not accept wstring that's the case where using .string().c_str() (which will "cast" a wide windows path to a narrow string).

one thing to think about (in the larger project of accepting all possible windows unicode paths) is that anytime .string() is used in windows environment, there is a risk of throwing an exception, if some of the windows unicode is not convertible into a std::string. I think this means all calls making use of .string should be try-catched, with the error failing a bit gracefully. the case would be to have a user with a directory path or file containing such a character.

so with this in mind, freeimage stuff is good to go (because it handles wstring) but for instance xmlsettings (which does not support wstring paths) maybe:

bool ofXml::save(const of::filesystem::path & file) const{
    try {
       // stuff
    } catch (...) {
       ofLogError("ofXml does not support windows wide unicode paths containing unconvertible characters");
    }
}

it seems hard to test as it depends on the encoding of the file, so simply pasting a test string might not trigger the exception (because some conversion would occur at the text editor point). this gives an example:

https://stackoverflow.com/questions/77254635/error-with-character-mapping-when-conversing-filesystempath-to-string-or-print

but it would be good to install a test that sends such as "bad" string to the various path-handling functions and trigger problems.

[dimitre]

Great. I think we should identify on core where this kind of conversions happen and treat in a separate PR.
I would prefer making a core internal function (maybe ofPathToString ) to be used in core with the try / catch in one place only.
I'll be merging this one as it is so I can fix potential conflicts in other PRs
enjoying my nice temporary window of availability for OF ideas

[dimitre]

ofPathToString PR here :

• ofPathToString to try / catch errors if wstring has impossible characters #7799