We've been kicking around an idea to take QC plugins up a step.
Right now, there's a ton of duplicated header information in each plugin's source code. Each time we discover something new about the internals of QC, we update the project we're working on, but those changes do not get applied to all the plugins that already exist. This has caused some confusion (which our 0.5 template release scheduled for later today should amend somewhat, albeit temporarily).
There's also a pretty big lack of inter-plugin resource sharing. This isn't too important now, but as more plugins take advantage of customizations not available in the QC core itself, more code gets needlessly duplicated, and, more dangerously, more code gets to suffer bitrot, and slowly drift away from more active projects' upkeep.
To address these issues in upcoming releases, we've decided to start work on a plugin/project called 'KinemeCore'. This will be a framework for other plugin developers, and a plugin for QC itself. The framework will help keep all plugins synchronized with the latest template headers, and will allow them to take advantage of updates made in later plugins.
The first beta release of KinemeCore is quite a ways off. However, the better we plan on it now, the more robust and powerful it will be when the time comes.
Here are some features/ideas we've been considering:
- A modified fork of Sparkle for automatic updates for all plugins (handled by the KinemeCore plugin, so plugins require no additional code, just some plist settings).
- Numerous port-type enhancements. Presently, we're working on "transparent array" ports that behave like single values to non-array-aware ports, audio ports, 3d data type ports (from points up to models and skeletons).
- along with the above, we're also planning on making a QuartzCore test suite which will profile the internals of the QC runtime objects. We plan to find slower objects, and possibly re-implement them to respond faster. This will be transparent to users and developers, they'll only notice more nimble execution.
- Convenience methods for common application needs, to make QC-aware applications a bit more versatile. This includes loading plugins from arbitrary locations on the fly, creating compositions from raw bytes instead of just files, and perhaps even a programatic interface to allow compositions to be altered on the fly.
- possibly some wrapper layers for easier Tiger/Leopard compatibility for plugin developers. Images and OpenGL are in need of this, with OpenGL being trivial, and Images being more non-trivial.
What are some other features that would help out QC users, excluding more patches :)? What are some features that would help QC plugin developers?