AcademySoftwareFoundation / AcademySoftwareFoundation/openfx
New C++ helpers
- 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
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