ofx addons feature request(s)/thoughts(?)

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.

I’m not the maintainer of ofxaddons so I’m not a 100% authorative source, but I think I can still shed some light on some of your questions.

The “official” addon structure as given in http://ofxaddons.com/howto is really young, it’s only been about for a couple of months. Many addons are older than that, so they diverge from this.

“ofx” prefix is for addons (x like eXtension, I guess). If an addon has a name like ofSomething, that’s wrong.
We use the ‘of’ prefix for global functions, and class names. eg ofImage, ofSetColor, etc., as per the naming conventions in https://github.com/openframeworks/openFrameworks/wiki/oF-code-style

A mechanism for addons to indicate version compatibility and/or dependencies is currently in the works, but it’s not decided yet how this will look like in the end.

If you want to try all the addons, you actually only need to clone the repo - master, develop are there, and 0061, 0062, 007 are available as git tags, so you can easily switch between those.

If you find errors and/or incorrect/incomplete documentation, it would be great to contact the addon maintainer to get him to fix it. It is unfeasible/impossible for the ofxaddons admins to check/vet every addon on the page. ofxaddons is a mostly-automated directory which crawls github and presents to you a collection OF addons in a nice way.
A mechanism to indicate up-to-date-ness of addons will most probably be added in the future.

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.

I don’t get what you’re trying to say here. current ofx?
Anyway, the stance of the core devs (afaik) is that only stuff which is useful to a high percentage of the OF users will make its way into the official repository. Also, many example projects for functionality in the OF repo are in there, the project files will be autogenerated (already set up). Addon maintainers are encouraged to provide examples with their addons.

hope that clears things up a bit.

Thanks for the feedback bilderbuchi. You gave me some context that helps.

Sorry if I was unclear, by “current ofx”, I meant the most recent openframeworks on github, whether the master or develop branch.

The only thing that I wonder about, is the judgement call on how to decide what is useful to a high majority of users. No big deal :slight_smile:

I think maybe I’d tend towards thinking it would be good to push stuff to the core as soon as it’s working, and see how it fares through a few iterations, but maybe there would be some downfall to that. I just see a great deal of duplicate effort on similar addons, whereas it seems like dedicating efforts to one library/addon/whatever that accomplishes that function would be more fruitful. Maybe what I’m suggesting wouldn’t solve that though. I can see the upside to “why it is like it is”, and the flow of development is pretty cool and organic as is.

The problem is if you start stuffing things into the core, it becomes the core devs’ responsibility to maintain/update/develop the code. Since everybody’s resources are limited, you have to think hard on this. Also, the repo would get bigger and bigger with stuff not very many people need. Furthermore, especially with the upcoming mechanism of autogenerated projects, it’s very very easy to add addons to a project, so there’s really no need to have it in the core.
Another downside is: As soon as something is in the core, it’s there to stay. You can’t easily rip it out again because this would break people’s projects’ code - you don’t wanna do that. So you really have to think twice before adding stuff.

Regarding the duplication: I think this at least in part stems from the fact that coders want to write their own code instead of recycling/improving/getting to know existing code.
Another part is the (until recently) bad discovery mechanism. Now that ofxaddons is here, it’s much easier to go look in a central place to see if what you need is already there, so I hope duplication will decline in the future.

edit: Have you read the design philosophy part here: http://www.openframeworks.cc/about/ yet?