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

[GitBruno]

Yes please!

[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'll be saving here a commit in a fork that properly initialize all GLM values and remove unused definitions
GLM_ENABLE_EXPERIMENTAL / GLM_FORCE_CTOR_INIT
dimitre@c2da2ca

[dimitre]

Having only glm::mat4 initialized is enough on the core and addons (ofxAssimpModelLoader needed changes)
unitialized vec3 seems to be OK

[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 (comment)>, 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>

[dimitre]

You mean using a static library like libglm.a ?

[danoli3]

Yeah whats stopping us compiling it with these defines wouldn't that work

[ofTheo]

I think it's a header only library for the reason that it allows the compiler to inline functions and optimize the code more efficiently.

[dimitre]

Shared pointers dance

I'm wondering if we can have a struct with lots of needed initialization things for OF, so it is more clear to see what is going on and we can reduce the number of shared pointers are being called for things like ofGetCurrentRenderer, etc.
as a proof of concept I worked in a PR and made this structure ofCoreInternal here:
https://github.com/dimitre/openFrameworks/blob/213cd4afbf5fb115b472333a9aad2a16bf9f0a61/libs/openFrameworks/app/ofAppRunner.h

it seems to be working OK. I'll be applying this in a separate branch and test in projects soon

[dimitre]

Install script

just one install script to install dependencies and libraries, autodetecting platform
with optional parameter to supply platform if crosscompiling for ex.

[danoli3]

already started
./of setup
./of update
./of upgrade - update old projects / update old addons (with sed )
these will be commands auto run by buttons in new UI PG

[dimitre]

Error: Script for ['setup'] not found or not executable at: [/Volumes/tool/ofw/scripts/macos/setup.sh]

[dimitre]

Deprecated Functions

remove them. or encircle them with
#ifdef USEDEPRECATED
so the symbols don't need to be compiled, be present on autocomplete, etc.

[dimitre]

Type Conversion

reenable the warnings about 64/32 bits implicit conversion and tackle all of them

Implicit conversion loses integer precision: 'std::size_t' (aka 'unsigned long') to 'ofIndexType' (aka 'int')

Are there some special motivation about ofIndexType being TESSindex?

typedef TESSindex ofIndexType;

[dimitre]

I think one worrying conversion is this:

[dimitre]

macOS enable hardened runtime

Enable in macOS template, this is a great improvement to easily submit apps to app store. I'm testing this now in a fork, working great.
PS: disable library validation, so it works with ofxSyphon (different signatures for app and libraries)

[dimitre]

I was unaware, Syphon won't make to the app store

[ofTheo]

if you are having issues with it - you can force sign all frameworks etc with your distribution identity that will override any signing ofxSyphon has

[dimitre]

Ah no in fact it uses a protocol that is not allowed in app store sandbox.
it is a known issue from 2014
Syphon/Syphon-Framework#10

[dimitre]

one more important entry for app store submission, in info.plist

[dimitre]

std::chrono for all timers

std::chrono is a well built, works the same for all platforms and doesn't make unnecessary divisions,
we can use end to end on time objects and avoid conversions like:

constexpr uint64_t NANOS_PER_SEC = 1000000000ll;

I'm using like this and I can see differences in ofGetElapsedTimef() and similar.

[dimitre]

ofNodeMesh

it would be great to have an object deriving from ofMesh and ofNode at the same time.
something in the likes of of3dPrimitive but easy to set Position or consolidate transformations to mesh

[GitBruno]

We need a better node tree. We should be able to grab a branch for example. Or walk a tree up and down efficiently. I tried to solve this by wrapping it inside an ECS. And instead of the notify Event which creates loops just have it flagged dirty and do a single system update.

[dimitre]

RPI Precompiled

As some great raspberry pi (3B+) are slow to compile the entire OF core
it would be great to cross compile everything in runners, and package the results .obj .d .a in the zip file
to test if it can save time compiling only project and addon files.

[dimitre]

Move remote file loading (http / https) to a core addon

This is already made in ofWorks fork.
moving aside from core libssl / libcrypto and libcurl we shave off 3 / 4 megabytes from the binary, compiling faster
system frameworks (Foundation and SystemConfiguration) are moved to the addon also

[dimitre]

ofxCairo

• moving cpp files and libs from core to ofxCairo

[dimitre]

RGFW

Add RGFW as an alternative to GLFW (it can work as GLEW also)
https://github.com/ColleagueRiley/RGFW

[dimitre]

File Dialogs / Alerts in Linux

Using Zenity, remove GTK from Core.

Alert =
zenity --info --text=TEXT

std::string ofSystemLoadDialogPortal(const std::string & title,
                                     bool bFolderSelection,
                                     const std::string & defaultPath)
{
    const char * zenity = "zenity";
    if (bFolderSelection)
        zenity = "zenity --file-selection --directory";
    else
        zenity = "zenity --file-selection";

    char cmd[512];
    snprintf(cmd, sizeof(cmd), "%s --title='%s' 2>/dev/null",
             zenity, title.c_str());

    FILE *pipe = popen(cmd, "r");
    if (!pipe) return "";
    char buffer[PATH_MAX];
    if (fgets(buffer, sizeof(buffer), pipe))
        buffer[strcspn(buffer, "\n")] = 0;   // strip newline
    pclose(pipe);
    return buffer[0] ? buffer : "";
}

[dimitre]

RM ofVAArgsToString

And all other functions that call it internally. not secure and not very helpful in 2025

[dimitre]

ofVideoGrabber, open device by name or names

I'm working on an app that uses a specific IR camera to do openCV and other variable cameras to be RGB ones.
so I thougth of two helper functions on ofVideoGrabber.
One open device by name if existent, other open the first name to appear in a list of usable cameras, this way I don't have to worry about IDs order in different platforms, and avoid using laptop camera also

	if (camRGB.setDeviceByNames({
		"c922 Pro Stream Webcam",
		"C922 Pro Stream Webcam",
		"Logi C270 HD WebCam",
		"USB Camera VID:1133 PID:2085", // logitech c270 no mac
	})) {
		camRGB.setDesiredFrameRate(30);
		camRGB.setup(1280, 720);

	} else {
		cout << "Camera RGB not found from list." << endl;
	}

[dimitre]

ofBuffer accepting fs::path for initialization

Substitute in core where ofBufferFromFile is needed, so it is one less copy on buffers.