addons plan / info for 0.05

hi all,

just wanted to give some heads up and info about addons. they have presented a real challenge, but we think we have a good solution and we will release it soon.

To clarify, an addon is some additional code / libraries that extend openframeworks and add additional functionality. It will be a way of adding in support for different types of functionality which is not necessarily included in the core OF code, such as opencv, network, OSC, midi, shaders, etc.

Our goal in the future is to make this as simple as possible, because this is one of the harder parts of working with C++ / compilers: adding code and libraries to a project. The solution we have will work and may lend itself to automation. The other goal is to make these addons easy to update and support.

So here are some features of the new addon approach, and some info about it :

  • all addons will be just one folder for all compilers / platforms
    the folder will contain an xml file called “install.xml” that contains human readable / machine readable info about steps for installing

  • users will have to install the addon to the OF directory (basically copying the addon in, and putting some code in ofAddons.h. Users will then add that addon per project that they want to use it in

  • starting with OF 0.05 we will release OF core and OF fat. the core will be the same as before - core OF and examples. OF fat will include most common addons (opencv, network, etc) and examples of their usage, also one mega example that includes them all just to check for incompatibilities etc

to give some indication of what it will look like, here are some screen shots. we’ve done mac, windows and are just working on linux so it should be really soon.


what the addon folder will look like


each addon folder includes src, install.xml and necesssary libs, etc


also, the addon will have everything needed for all platforms and compilers While at first, an addon might not support all targets, we hope over time different folks will help with that support. We will try to post guides about porting addons, etc.


a look at the install.xml file
The xml should be an instruction set of how to install for the OF folder and for the specific project you want.


how to use an addon, once it’s been installed to the OF folder and to the projectit works from #define – you say what you want to use and the addons.h does the work of getting the addon loaded, via code like this:

  
  
//-------------------------------------------- ofthread  
#ifdef USING_ADDON_OFTHREAD  
	#include "ofThread.h"  
#endif  
  

To compliment the addons, we are also developing a new website on a different host (we are currently on dreamhost and they are http://digg.com/tech-news/Dreamhost-mistakenly-bills-customers-for-multiple-years">terrible)
. that website will use drupal / projects (like : jquery.com) in order to allow folks to upload and maintain their own addons, etc.

So - that’s where we are heading. We would love feedback, and we hope to have this really soon. Thanks as always for the patience and support.

over n’ out -
zach

… looking good! I am very excited!

One question … is the #include “ofAddons.h necessary”? What stands against ditching it and doing it like this:

  
  
#define USING_ADDON_OFXML  
#define USING_ADDON_OFNETWORK  
  
#include "ofMain.h"  
  

just a thought,

thanks!

we did try this, so that users don’t have to think about including ofAddons.h, but this was created issues:

a) addons need to include ofMain to get access to OF includes… so that obviously presented a recursive include problem, ie

ofMain -> ofOpenCv -> ofMain

b) to solve that we broke out ofMain into ofCore and ofAddons in 0.04, (so addons would include ofCore, and ofMain include ofCore and ofAddons) but this created more esoteric include problems, since includes are passed “down” the chain, as opposed to just being included with that given file, so we wound up with objects down the chain that needed an addon not being able to get access to them.

to solve all this, we decided that it just makes sense to split the two include systems. Our previous attempts to merge them had not proved too successful. the current system seems to get past those issues, with the added benifit of keeping the addons self contained (in the addons folder) and easily removable. Our initial tests all seem to be positive, but we’ll put it up soon and keep our fingers crossed.

take care,
zach

I’ve been building a number of UI classes for doing simple things like handling radio buttons, check boxes, buttons, using OFW’s built-in draw functions.

Would it make sense to make an addon out of these? Or is including ofMain in an addon really impolite?

If not, I imagine I would just include the classes in ofAddons.h? I did try this, but got freaked out when my xcode project broke down… maybe I’m missing something.

screenshots/code here:
http://a.parsons.edu/~magicplusplus/students/cameron/?content=a3

thanks!

-C

yes - def, that’s the idea of addons :

reusable code that can be brought into a project. you can include ofMain no problem in your addons. there is a funny .h file include order hack we had to make (see above description) in order to get this to work.

if you are curious and want to try, download this work in progress snapshot

http://www.openframeworks.cc/files/0.05-addonsWork/

the mac one is called “005” – in the mac one, there is a project called “all addons” that has all the addons added into the project.

we just got linux up (all addons) and will be fixing these examples up alot. The devcpp in that folder is more up to date (ie, the xml file is better structured, etc). you can download both and see the differences.

hope that helps!!
zach

I everybody !

I just wanna say that I can’t download the 0.05’s documentation.

By !