Dan Rosser

Sounds like just need to fix ofxCv On Mon, 14 Oct 2024 at 7:06 am, alexandre burton ***@***.***> wrote: > @roymacdonald the tests are here: > https://github.com/openframeworks/openFrameworks/blob/master/tests/utils/fileUtils/src/main.cpp > > (where...

file::path changes changes actually fixes the issues on Windows / all platforms for supporting Chinese UTF8+ folder paths so, best to keep them in core and have this work around....

std::filesystem::path generally works with std::wstring because the underlying file system uses UTF-16 (wide characters) for Unicode support. Meanwhile, in Linux and macOS, **std::string (UTF-8 encoded)** is commonly used so string...

osx. macOS is meant to be the super project, however I parked it after the issues with project configuration. I think I can fix it up for v12.1.0

Yeah probably. Error is fmod I think should be deployed to macOS folder when downloading OSX. The issue is the makefile is deploying to the macos folder in the final...

Pretty much the idea is for macOS project, which I forgot to fix up recently, but is a mega project capable of all outputs. The template needs to be linked...

Looking at this again as projectGenerator fixes almost complete now. macOS Super Mega project needs some work, but once I merge in the Metal ANGLE stuff, hooley Dooley

I think its maybe best to just put the OSX xcframework download into the /macos/ folder as the macOS super mega also includes the MacOS slice. This way we work...

@dimitre in the make files, when you did the osx-macos change over stuff, was there much there we need to consider

I made an example as this requires a bit of main.cpp setup and understanding of the limitations and powers of this GLFW passThrough.