Give ability to register types without needing to include DSL
Yay first specs...
Properly requiring jrubyfx
Add include_method_missing spec
Ensures DSL files get loaded, even when within jar, called from java
class.
Re-Write fxml demo as if it was designed by Rubyists

- update Demo.fxml to include more buttons, a quit menu item
- attach events with on_#{event}
- initialize in a method called initialize
re-write event handler syntax to be on_#{event} instead of fx_#{event}_handler
clean event handler eiganclass definition

- instance_eval is redundant inside an eiganclass
- whitespace for readability
lookup elements by id with method_missing

- custom scene getter/setter no longer needed
- simply calling `root` will lookup '#root'
- you can `send :CamelCaseID` if you don't follow ruby conventions with your IDs
- storing nodes as instance variables is now lazy and up to the user
- there doesn't seem to be a way to prefer fx:id over id (sorry javaists) -- Scene#lookup uses CSS selectors
expose CSS-style selectors for node lookup

- expose scene#lookup as `find` # nil on not found
- expose scene#lookup as `find!` # exception on not found
- expose scene.get_root#lookup_all as `css` # [] on no matches
Follow Ruby conventions for FXMLController initialization, enhance defaults

- Create controllers with #self.new (not #self.load_fxml)
- Initialization method is simply #initialize
- Prevent FXMLLoader#load from calling #initialize (when #initialize has no args)
- use self.method_added to preserve 'constructor'
- Don't vomit 20 lines of garbage to STDOUT — Actually handle the situation correctly!
- combine #self.new_java, #self.load_fxml, and #self.new into a single elegant #self.new
- drop #initalize_ruby — what possible use would a second "constructor" milliseconds before the object is actually ready serve the coder? Why have two when one will do?
- #initalize_fxml is just #initialize
- pass args to #initialize in settings[: initialize]
- use an options hash to setup defaults (same as current JavaFX)
- Now users can specify :depth_buffer AND :fill (just set the scene's fill after using the depth_buffer constructor)
- if FXML root is a Scene ignore settings for Scene
rewrite `self.load_fxml_resource` to be more Ruby and less brittle

? - should this be a private method?

- Don't call Java's URL.new twice (use Ruby Classes instead)
- Don't use optional ()
- Don't call `return` explicitly
- Whitespace for readability
- Using caller[] is clever, but *HIGHLY* CONFUSING AND BRITTLE
- Remove the option to pass a numeric arg to caller[] always use 1 (0 - JRubyFX::Controller#new, 1 - subclass)
- settings[:relative_to] expect a file or nil (views are relative to file's basedir)

About caller[]
In the future, I'd like to see a MVC-approach to loading Controllers and Views, but for today caller[] works by locating the controller class definition, and searching  for a view relative to that controller. Using caller[] is a hack, and doesn't scale, but it gets the job done.
Organize Class as: Constructor, Event Handlers, Lookup, Helpers
Use Minimal Constructor instead of options hash
Update contrib/FXMLExample to use new conventions
Merge pull request #27 from edubkendo/java-launch-fix

Ensures DSL files get loaded, even when within jar, called from java
Merge branch 'make-it-sexy'
gitignore JavaFX Scene Builder .bak files
add rspec as a development dependency. Add basic spec_helper

Yes! You should depend on rake. Because the project has a Gemfile, a specific version of rake will be included in the bundle. By using `bundle exec rake` (or if the user uses rubygems-bundler, or …, or …) a guaranteed version of the gem will be used, and this will improve stability in the long run.
Adding color converter for scene