There may already be a standard for how to deal with this, so if there is and I’m not aware of it, I apologize in advance. I also apologize if this is just stupid or an ill fit for ofx.
When I browse through ofxaddons.com to checkout the generally awesome addons that people have made for ofx, a few things come to mind.
One, is that the structure of the addons folders are seemingly inconsistent at times. Some addons folders are constructed so that they have are “ofxcooladdon”, with the header directly inside, like ofxRange. Others have like ofxTextInputField have the header and cpp inside of a “src” file… this makes sense, especially if there’s other folders for libs or whatever.
On another note, when I downloaded ofxtimeline, I believe that all of the addons were in one file called “src”, yet when I opened the sample app xcode project, it was clear that it had been constructed so that the ofxtimeline addon actually had two folders inside of the src folder in the xcode project, one for “base” and another for “elements”. I believe I ran into some similar issues with other addons. The way that people present addons for dl seems very different at times, when the end folder structure may need to be the same (or entirely different).
It also seems like there is some inconsistency with naming convention - some stuff is “ofx”, some is “of”, some is “ofxblah” on the folder addon name, but “of” prefaced with the actual files. Is this a historical thing, remnant of older ofx versions?
Additionally, there seems to be no real effort or “good coding practice” suggestion to document what version of ofx an addon is currently working with, or what branch (master or develop).
It seems as though in order to make it easy on yourself, it requires that you have an install of the current master, the develop, and installs of 0062 and 0061 at least, if not also 006, just to go through the current ofx addons page and check out projects. It seems like with the big effort that must be put into some of these really great addons that listing something on the github page about what systems they’re working with/ofx versions, etc., would be a good idea, and maybe a prerequisite to being on the ofxaddons page?
It also kind of kills me when I see an app example for an addon, and then see that some lib has been modded on their install that they don’t note or another required addon has a couple of extra files on their install that they’ve added, but aren’t present in the actual git for that addon, and never have been. I’m unsure why stuff like that winds up on the addons page without getting bounced back to the dev for cleanup first? Is the ofxaddons page automated, or is it just a matter that it would be way too much of a pain to try to test stuff first or add notes about what config an addon works with/was tested with?
Also, this is probably really crazy, but it seems like it would be useful if there was a git of the current ofx (master and/or dev) with compliant addons and sample projects already setup, that people could attempt to maintain, instead of the more bare bones approach. This seems to be going away from the current push of auto generated samples and what have you, but it seems like it’s not a horrible idea.
Thanks for the great system, and I mention this stuff with the caveat that I’ve followed ofx since v002, but usually don’t use it for development, and use xcode / cocoa frameworks, openGL and glsl, and/or quartzcomposer. I’ve been more interested in ofx lately and am kind of tossing this out there, because I’m thinking I might be missing something in the way that addon management has changed throught ofx versions (?) that results in some of the inconsistencies I’m seeing.
