OF Vision

[dimitre]

I have a vision of how OF can be different.
Some ideas are compatible with the project and others not, I'll be using this space to share ideas and discuss them with you

[dimitre]

Libraries

I think we should be back using straight .a libraries whenever possible, the only place xcframeworks are indispensable are ios/simulator combo. This way we can simplify addon_config.mk to the point we don't ever have to use ADDON_LIBS for Core addons. if it is a standard .a file in its own path, ProjectGenerator will add it. if it is a xcframework it will also add to the project

[danoli3]

I think we should just replace makefiles with cmake and use find library with library path local and package manager paths provided.

Cmake is the future

[dimitre]

Libraries Path

I think it is confusing 3rd party libraries are together with openFrameworks and openFrameworksCompiled folder.
it would be great if they lived in a folder that we could wipe out anytime to reinstall

[dimitre]

I'm working on a fork with a different OF Core third party libraries path.
All libs in the same folder, and all includes in the same folder also
this way we can provide a lot less paths as compiler parameters and make it work with more specific paths on includes, like

#include <tess/tesselator.h>

instead of

#include <tesselator.h>

This is the only place I remember the core is invoking something outside "include" library for this part

.
├── macos
│   ├── include
│   │   ├── GL
│   │   ├── GLFW
│   │   ├── brotli
│   │   ├── cairo
│   │   ├── curl
│   │   ├── freetype
│   │   ├── glm
│   │   ├── libpng16
│   │   ├── nlohmann
│   │   ├── openssl
│   │   ├── tess
│   │   ├── uriparser
│   │   └── utf8
│   └── lib

the path is $ofw/libs/macos/

[danoli3]

openframeworks/libs/x

To openframeworks/libs/dependencies/x

So we can keep the folders clean for dev. In the end no one is navigating to these paths as often as us and it's those extra clicks to get to the core I understand

openFrameworks/libs/openFrameworks/ more accessible

[danoli3]

xcframeworks come packaged in the format you suggest with includes (wrapped) embedded, fixing issues with auto platform configuration headers
Hence their value for macOS and iOS.

'''
lipo -create libMyLibrary_arm64.a libMyLibrary_x86_64.a -output libMyLibrary_fat.a
'''

'''
xcodebuild -create-xcframework
-library path/to/ios-device/libMyLibrary.a
-headers path/to/ios-device/include
-library path/to/ios-simulator/libMyLibrary.a
-headers path/to/ios-simulator/include
-library path/to/macos/libMyLibrary.a
-headers path/to/macos/include
-output MyLibrary.xcframework
'''

[dimitre]

Assimp

removing ofxAssimpModelLoader and favoring ofxAssimp instead.
assimp libraries can be installed directly on ofxAssimp folder.
if we don't want to have ofxAssimpModelLoader removed at first we can at least switch the main one (with libs) to be ofxAssimp.
What do you think @ofTheo @NickHardeman ?

[danoli3]

Definitely !

[NickHardeman]

Yes, agree!

[dimitre]

Stop compilation on first error

-Wfatal-errors is very useful to stop on first error, because very often the subsequent errors are a cascade effect of the first one

[danoli3]

Great idea!

[danoli3]

Also maybe we add a check for all platforms, to see if it can link to the libraries. Package manager or provided and provide detail on that.

Also all external depends and the code that calls them define preprocessor disabled. Things break. Operating systems, packages and depends all the time. It would make debugging so much easier if we can disable any external depend by a flick of a switch. We started this but we should do this for all dependencies and libraries

[dimitre]

ofxSvg -> ofxSvgParser

removing ofxSvg from core and substitute with https://github.com/NickHardeman/ofxSvgParser
this way we get rid of libxml2 and svgtiny (which depends on libwapcaplet / libdom) and keep removing abandonware

[NickHardeman]

Happy to replace ofxSvg with ofxSvgParser. There are no library dependencies and any upkeep seems worth the time because we will have control over the source.
The name ofxSvg is more appropriate since I am currently working on writing / saving capabilities . :) I think it would just take a few function additions to ofxSvgParser to be backwards compatible with ofxSvg since there are only a few functions.
The naming / namespace approach is rather different though. Not sure if it all should be converted to ofxSvg or within a namespace like ofx::svg

[dimitre]

Version shy

OF is 21 years old and version shy. no 1.0 yet?
I suppose we should move to v12.1.0, more appropriate

[danoli3]

1.0.0 when all the platforms are working again!
Agree let's iterate versions each week until this is done

[dimitre]

XCode OF Core, one arch

it would be great if we achieve to compile the core in just the computer architecture,
with the possibility of building Universal Core / Project under a special configuration on Project.xcconfig

[dimitre]

Make

While we don't have an equal substitue it is the motor that runs OF.
Things I would change:

• Project: no need for Makefile and config.make. we can put everything in Makefile and that's it.
• Addons: it seems to brute force every path possible path and filter out some undesired later. We can work better on more precise GLOB to add less paths to addons (I'm already testing it)

[danoli3]

Will be replaced with CMake. CMake makes Makefiles automatically.

[dimitre]

GLEW

alternatives?
https://github.com/Dav1dde/glad
https://github.com/anholt/libepoxy

[dimitre]

GLFW Window

Simplify all different windows settings objects in just one, ofWindowSettings with everything (I'm alreading using like this in a fork)
Having a separate object, like windowHandler, so we query for example the number of monitors without having to create a window first.

[dimitre]

ProjectGenerator

Rewrite from scratch, ditch electron. having a separate discussion to disambiguate Platforms, targets, IDEs, build systems, templates.

[dimitre]

ofLog

I know this is impossible because of addons.
but this is beautiful https://github.com/gabime/spdlog

[dimitre]

GLM

Disable GLM_FORCE_CTOR_INIT and initialize all vars properly, like chaning

glm::mat4 localTransformMatrix;

to

glm::mat4 localTransformMatrix { 1.0 };

[dimitre]

if we are going to use minimum c++17 we can substitute all glm::clamp in OF Core to std::clamp
and remove #include <glm/ext/scalar_common.hpp>

related: dimitre@845257d#diff-8ff7947c3aca26e010c217a6e188e423d3f0ed95a71e5211e0309b09210af73e

[ofTheo]

GLM_FORCE_CTOR_INIT makes me nervous.
Everytime it gets disabled an addon or project breaks and it can take forever to track down.

This feels like low priority compared to other stuff.

Also as old OF addons that use ofVec3 / ofPoint get 0,0,0 constructors so GLM_FORCE_CTOR_INIT disabled, will result in uninitialized vars for those legacy projects, breaking things that are currently working.

[ofTheo]

That said, we should be doing stuff like:
glm::mat4 localTransformMatrix { 1.0 };

anyway :)

So if it does get disabled the core still functions properly.

[dimitre]

I've proposed a PR untangling glm and "classic math" operations, which avoids some strange interoperability that happens in the core like:
glm::vec2 -> ofVec2f ->ofVec3f -> glm::vec3

[danoli3]

Can we just compile glm

…

On Tue, 4 Feb 2025 at 5:46 am, Dimitre ***@***.***> wrote: I've proposed a PR untangling glm and "classic math" operations, which avoids some strange interoperability that happens in the core like: glm::vec2 -> ofVec2f ->ofVec3f -> glm::vec3 — Reply to this email directly, view it on GitHub <#8259 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGK2HFUTVBX3ZO3J34STBT2N62R3AVCNFSM6AAAAABVPKNGVGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBUGYYTMNY> . You are receiving this because you commented.Message ID: <openframeworks/openFrameworks/repo-discussions/8259/comments/12046167@ github.com>