[UPDATE September 1st, 2011] As of today this wrapper is available to download at its CocoaCinderGL wrapper page in the code section of this website. Enjoy!
This one is about re-wrapping the Cocoa version of the CinderView (wondering what Cinder is?) so that it will be usable as a typical custom view in XCode's Interface Builder. Why? Because then several instances of it may be used at the same time within the same Mac OSX application, and even be dynamically instanciated. Also because then, Cocoa's controls such as buttons, sliders, popup boxes and collection views may be connected to those instances of the CinderView. And that can be very, very handy when you want to build quick prototypes, with several windows and a native GUI. Two images are well worth two thousand words:
Those two illustrate the use of the Cinder framework in both contexts. Left, with the usual Cocoa wrapping. Right, with the "CCGL re-wrap" (for Cocoa'ed Cinder GL ;). Here under are a few examples of CCGL use, some of which are based on Cinder's packaged samples.
To start with, the multi-CinderView example, probably the most relevant:
An OpenGL lighting example, with a material specularity slider:
Paul Houx's great GLSL and picking 3D sample, reloaded:
A trimesh loading and vertex selection example, with a toggle allowing to show|hide handles:
There had to be a particle example, this is Cinder after all!
A first look at the reason why I started working on this wrapper. Here you see a CollectionView, 2 CinderView's and several buttons all working together:
Coming from Processing + Swing
Just like everybody else, I've started the whole creative coding thing with Processing. Soon, I've had the need of building complex GUI's with several PApplet instances, several windows (see Cimes for an example). That's how I started using Processing as a library, within the Eclipse IDE. First by analyzing the *.java export of Processing sketches and following Proclipsing-like procedures, and then with Proclipsing when it came out. The GUI was usually Swing based.
Cinder + Cocoa + Interface Builder allows for such an amazing "coding experience" that I think I can never go back!
How does it work, and where is the catch
At some point, you've got to write a little bit of Objective-C, and the main files you're handling are *.h and *.mm instead of *.h and *.cpp. But frankly, when used appropriately (i.e. left aside for typical C calculations), ObjC can really speed up production and help write human readable code. Also, I tried to build the wrapper in such a way that when I'm making a very simple app, it's got a feeling of building something quite simple indeed (i.e. went through choosing defaults for several parameters, once and for all !). So all in all, I think it's fair to say it makes using the Cinder framework slightly more difficult, but all the more rewarding when you need that kind of functionality such as multiple CinderView's and native Cocoa controls in the same application.
What's next... interested?
I'm not sure yet whether I will be releasing the wrapper with samples and howto's at some point... just got to wrap my head around it. It would be very cool & very helpful if anyone would say whether that'd be of any use to them. Email me at contact@smallab.co or use the comments section below. Cheers!