ugh, is it july already?

so the processing book is coming along.. lots of work by casey, in fact i'm not sure he realizes (or wants to realize) that it's summer. then again, he's in LA and presumably it's always summer there.

for my end of things, i've also been helping on the processing book and working on the guts inside core. some of the latest:

+ the move to eclipse has been somewhat postponed. the guy who was helping me with it is now awol, and the advanced stuff is over my head.

+ however, processing.core, and each of the libraries are now proper eclipse projects. this means that you can use subclipse (or subversion) to check out any of these subdirectories, and use that from within your eclipse project, almost the way you would with p5 itself. i.e. you do a project that requires core and opengl, so you just include those projects as part of the build path in eclipse. buuuut.. i wouldn't necessarily start using it just yet because:

+ the version of p5 that's currently in subversion is a mess. if you're checking out the code, you should use a tagged release version (i.e. processing-0115). lots of things are changing daily and could break things for you.

+ the finalization of the api for 1.0 continues. the renderers have been renamed so that they're more descriptive:

- PGraphics - name is unchanged, this will just be a base class that includes basic operations that can be overridden.
- PGraphics2D (P2D) - the return of the speedy renderer from the alpha days. no more using P3D to get fast video and image stuff.
- PGraphicsJava2D (JAVA2D) - formerly PGraphics2, this will remain the default renderer because it's more complete than P2D.
- PGraphics3D (P3D) - formerly PGraphics3
- PGraphicsOpenGL (OPENGL) - formerly PGraphicsGL

+ there are some other minor api changes. i won't be doing a release until i have time to finish a sketch "updater" that will find/replace old api and replace with new api. this won't be perfect, but will at least be able to flag api that has changed and hopefully update it for you.

+ i don't think we'll be doing a release for a while (we may do internal-only releases or release to a smaller set of people as we iron out some of the kinks. we may go submarine style the way we did between 0069 and 0085.

casey and i have also been discussing the actual role of processing and how it fits with the community. we're looking to (even further) shift the focus away from processing itself, and onto the contributed libraries. this is how we can make the open source thing work, it's where processing is most interesting, and it fits our idea of avoiding the upgrade treadmill found in commercial products. i'll write more about this later when i have more time, but the general result will be:

+ improvements to processing post-1.0 will focus on the stability and simplicity of the ide. for instance, making the compiler give better error messages, or integrating ecilpse-style code guidance/warnings/completion that will make coding smoother for our audience.

+ we're looking to improve the library api and make it easier to create libraries and renderers. this will be a combination of documentation, and adding some kind of find/download/update mechanism for libraries. same as for libraries goes for "tools" that will go in the tools menu. this will allow others to extend the ide.

+ we'll start relying more on contributed libraries for "features". that is, we may never do the AGG library ourselves, but might help it along via other developers. or things like export to movie (thanks dan shiffman), or fancy image saving, etc will remain external libs. i need to figure out how i can best support library developers to do this sort of thing, rather than trying to take it on myself (i have many ideas for this, and how the whole process needs to be improved, more later). it's tempting to pull these projects into the core api, but it makes for a behemoth.

so that's enough for now, but should give you a taste of what's coming.

previous status report:
http://processing.org/discourse/yabb_beta/YaBB.cgi?board=Collaboration;action=display;num=1147792441

concerning the contributed libraries, it seems quite important to me, that, at least as long they are featured here, those should be open source, too. unfortunately, this is not always the case.

it's not that i wasn't grateful for the individual contributions. OTOH i am getting tired of having to deal with smaller or larger glitches whilst being immersed in a project w/out being able to handle appearing issues with a library _immediately_ and _on my own_. and even if somebody would – presumably unlawfully – use a decompiler like jad on the library's jar file, this person still would not be able to contribute (bug fixes || improvements || extensions) to the community.

Thanks for the status, seems quite sound.

I'd be interested in two capabilities, both of which are likely possible now, but if not, would be nice for the future.

1 - Java 1.5, 1.6, ... etc.  The goal would be to be able to use Processing from Eclipse, NetBeans or other IDE as cleanly and easily as possible.  Not requiring Processing itself to be built in more recent versions, but simply being able to be used by 1.5 etc.  Why?  Well you've built such a great system, that we are using it for ambitious projects that would benefit from some of the simplifications 1.5 etc provide.  Here is one example of our use:
http://www.backspaces.net/models/Stadium/applet/
Note: hit "f" to see a Blender-built stadium

2 - Jython, Groovy, JRuby .. etc.  The goal would be to allow even faster prototyping for folks who have drunk the "agile" kool-aid.  For some of our users, the Java annoyances and verbosities are pretty hard to overcome.  So being able to use Jython, for example, would be quite a help.  We don't know if the performance hit would be prohibitive, but it is an area we're looking at.

So the big picture for us is to be able to use Processing in fairly complex projects, and to allow non-java programmers to build prototypes in a simpler language.

Boy, and a big, big THANKS for the absfab project!  You've absolutely changed our project lifecycle.  We've got 3D modeling going on in Blender, imported into Processing for Agent Based Modeling, and exporting the results back into Blender, with render farm uploads for very realistic movie creation for our clients who need fairly realistic visualizations.

   -- Owen

Owen Densmore  http://backspaces.net   http://redfish.com  http://friam.org/