AcademySoftwareFoundation / AcademySoftwareFoundation/openfx

New C++ helpers

Open
#181 5 comments 0 reactions 0 assignees View on GitHub
standard change
Dominant language
C++
Stars
570
Forks
152
PR merge metrics
No merged PRs in 30d

Description

# Open Effects Proposal for Standard Change

Please read the contribution [guidelines](https://github.com/ofxa/openfx/wiki/Extending-OpenFX-Guidelines#submit-a-proposal-or-bug-report-to-review) first.

## Standard Change Workflow
- [x] Create proposal as issue (you're doing this now!)
- [x] Tag this issue with `standard change` tag
- [ ] Identify subcommittee: at least one plug-in vendor, and at least one host
- [ ] Discuss the idea in this issue
- [ ] Write new or updated code and doc
- [ ] Publish updates as a pull request (ideally on a `feature/PROPOSAL-NAME` branch)
- [ ] Make sure that PR references this issue number to keep them in sync
- [ ] Discuss and review code in the PR
- [ ] Meet all requirements below for accepting PR
- [ ] When subcommittee signs off and other members don't have any further review comments,
maintainer merges PR to master which closes PR and issue

## Requirements for accepting a standard change:
- [ ] Header files updated
- [ ] Documentation updated
- [ ] Release notes added
- [ ] Compatibility review completed
- [ ] Working code demonstrated with at least one host and one plugin
- [ ] At least two members sign off
- [ ] No further changes requested from membership

## Summary

I’m beginning to work on a “modern C++” openfx-cpp support lib that will be more maintainable, type-safe and easy to use, as well as reflecting the C API more directly. I expect to contribute this to the main repo at some point. A couple of questions for you:
- Would you use such a thing when creating new plugins?
- Should I aim for C++20 (better, more compile-time type safety etc.) or C++17 (in more common use today)?
- Are there particular pain points you have with implementing plugins using the C API? I’m thinking initially about props, params, clips and images.

## Motivation

The current C++ support lib is very out of date, and hasn't been updated in a long time. It also doesn't use any modern C++17 or later elements, so it is clunky to use. It also works only as a complete framework, not as an incremental add-on to the C API. This proposal is for a more minimal set of C++ classes for clips, images, properties, and parameters, to simplify access and ensure type-safety. It uses the new type info for all built-in properties and property sets to enable simple type-safe property access.

## Problem

The goal is to simplify development of new plugins for new users of the API, while staying true to the original design goals of simplicity, compatibility and extensibility.

## Impact

This is entirely plugin side, and has no impact on the C API at all.

## Documentation Impact

The new helpers will need documentation as well as sample effects.

## Stakeholders

This is intended for plugin creators.

## Discussion

Initial implementation is taking place in the https://github.com/AcademySoftwareFoundation/openfx/tree/props-metadata branch, see #166 .

Contributor guide

Open the contributing guide

Research direction

Read the contribution guidelines linked in the proposal, then review the props-metadata branch and issue #166, where the initial implementation is taking place. The scope covers C++ helpers for props, params, clips, and images; completion requires updated headers and documentation, release notes, compatibility review, demonstrated host and plugin code, and member sign-off.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.