Hi L-P.

This is the one portion of the current API that I'm quite conflicted about. Here's the backstory:

The Processing methods (stroke, fill, width, etc) are not actually global functions ... it's simply that the magic of Java's inner classes give all inner classes access to the methods defined in the enclosing instance. Ruby does not work this way in the slightest.  Inner classes in Ruby are just ordinary classes that happened to be scoped to the enclosing class. They have no special access to variables or methods outside of themselves.

So, this presents us with two alternatives, the first -- what Ruby-Processing currently does -- is to do nothing, preserving the traditional Ruby-way of doing things. The other option would be to do something fancy with method_missing to forward all method calls that hit the top scope on to the current Processing sketch. The unruby-ness and performance implications of this approach make me reluctant to implement it. So, for now, if you want to call methods on the sketch from another class, the easiest thing is just to use the convenient global variable, $app, to do it.

I'll take a peek at how slow the method_missing alternative is, and maybe we'll get that in 1.0.6. If anyone has a better idea of how to implement it ... please chime in.

a simple way to build over the $app var could be to play with eval like this:

module ProcessingApiRuby
 %w[stroke fill rectMode rect].each do |generic|
 eval("def #{generic}(*args); $app.#{generic}(*args); end\n")
end
# this is not a complete working example again,
# but its working code..

would be nice to have some for 1.0.6!!!
btw, ruby-processing really rocks!!
Thanks!

pretty clever hack!!
I didn't knew about this "included" method, and truly I'll need to read more about it before I really understand what it's doing...

so, here are the cues I can give you as a tester:

First, It worked!!, but not all methods seems to be present? (this may be intentionnal I don't know) like, I had a rectMode in my small test and I needed to call it from $app for it to work, but other methods like stroke, fill, rect all worked fine.

Second, constants like CENTER, kinda cutted the impression my nested class had access to the nesting class scope, because I still needed to access them with the fully qualified name Processing::App::CENTER.

Last, I really like the way this makes nested class behave like it would in the Java Processing API.  Transparent and natural to the user, really a great gain!!!

My only remaining question was about building classes as generic external widgets libraries...  I then realized I could simply "include Processing::Proxy" in my external class and voilà!  That simple trick would make it Processing aware, allowing sketch independent classes to be built and used as libraries.

Remarkable step I think,
Big cheer for Jashkenas!

p.s. my test was on a really simple example, involving only one nested class, then moved it to be an external required class... so it cannot be considered really extensive testing, I would doubt more complex scenarios would break the hack, but I will try to break it anyway when I get more time to do so later today.

Okay, 1.0.6 is out, with inner classes and a couple of other patches. Thanks for helping make it happen.

very nice indeed. in case anyone else is wondering what this is about, here's a most simple example:

Code:

# Inner Test

class InnerTest < Processing::App

  def setup
    @test = Test.new
  end
  
  def draw
    @test.drawTest
  end
  
  class Test   
  # the inner class Test, which now can call 
  # the outer PApplets "rect" function
  
     def drawTest
	 rect 20, 20, 100, 100
     end
  
  end
  
end


InnerTest.new :title => "Inner Test"
 

F

If either of you notice any more methods that should be available on the proxy (besides width and height), post 'em to this thread, and they'll make it in the next release.