hotcocoa 0.5.1 → 0.6.0pre

data/.yardopts

@@ -0,0 +1,14 @@
+--no-cache
+--no-output
+--verbose
+--markup markdown
+--markup-provider redcarpet
+--readme README.markdown
+lib/**/*.rb
+-
+History.txt
+docs/Contributors.markdown
+docs/Overview.markdown
+docs/Resources.markdown
+docs/Tutorial.markdown
+docs/Mappings.markdown

data/History.txt

@@ -1,3 +1,24 @@
+=== 0.6.0 2011-10-xx
+
+* 8 enhancements:
+  * New application builder to work with MacRuby 0.11
+  * Application templates now use an appspec, similar to a gemspec
+  * Truer lazy loading for mappings (may break custom mappings!)
+  * API documention (67% coverage so far)
+  * Regression tests (< 67% coverage so far)
+  * Updating and porting of the tutorial documentation (~40% complete)
+  * HotCocoa now works when compiled
+  * HotCocoa is now leaner and meaner
+
+* 3 new mappings:
+  * NSNetService          => bonjour_service
+  * NSNetServiceBrowser   => bonjour_browser
+  * NSBezierPath          => line
+
+* 2 graphics improvements:
+  * Image class works with more image types
+  * Image class can save images
+
 === 0.0.1 2009-11-07
 
 * 1 major enhancement:

data/README.markdown

@@ -0,0 +1,84 @@
+# hotcocoa
+
+* [http://github.com/ferrous26/hotcocoa](http://github.com/ferrous26/hotcocoa)
+* [Documentation](http://rdoc.info/github/ferrous26/hotcocoa/master/frames) WIP
+
+## Description
+
+HotCocoa is a thin, idiomatic Ruby layer that sits above Cocoa and
+other frameworks. HotCocoa used to be included in MacRuby but is now
+managed as a separate gem.  This will allow HotCocoa to accept
+contributions and evolve more quickly. To see more information on
+HotCocoa (including tutorial) see
+[http://macruby.org](http://macruby.org).
+
+## Note
+
+This is a fork of HotCocoa that is being kept alive by myself and
+other contributors; most of the work now is going in to documentation
+and regression tests, but we are still adding new mappings, improving
+existing mappings, and adding other features that we feel help meet
+the goals of this project.
+
+If you find issues with HotCocoa you can open issues and I (or
+another contributor) will try to fix them.
+
+There are a list of
+[gotchas](https://github.com/ferrous26/hotcocoa/wiki/Gotchas) in the
+wiki.
+
+## Install
+
+* sudo macrake install
+
+This fork is only available from source right now.
+
+Note: If you are on Snow Leopard, you will also need the
+[Bridge Support Preview](http://www.macruby.org/files/BridgeSupport%20Preview%203.zip)
+in order to run this fork of HotCocoa. Read about it on the
+[MacRuby Blog](http://www.macruby.org/blog/2010/10/08/bridgesupport-preview.html).
+
+## Documentation
+
+Documentation is a work in progress; some of the documentation is
+being ported from the MacRuby website where it is still available.
+
+The documentation does not include the mappings right now due to the
+way that mappings are implemented; a YARD plug-in is needed for that.
+
+## Contributing to HotCocoa
+
+* Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet
+* Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it
+* Fork the project
+* Start a feature/bugfix branch
+* Commit and push until you are happy with your contribution
+* Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
+* Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.
+* No contribution is too small!
+
+## License
+
+(The MIT License)
+
+Copyright (c) 2009-2010 Richard Kilmer
+Copyright (c) 2011 Mark Rada
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+'Software'), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/Rakefile

@@ -0,0 +1,47 @@
+task :default => :build
+task :build   => :gem
+
+if MACRUBY_REVISION.match(/^git commit/)
+  require 'rake/compiletask'
+  Rake::CompileTask.new
+end
+
+require 'rake/testtask'
+Rake::TestTask.new do |t|
+  t.pattern   = 'test/**/test_*.rb'
+  t.ruby_opts = ['-rtest/helper']
+  t.verbose   = true
+end
+
+require 'rake/gempackagetask'
+spec = Gem::Specification.load('hotcocoa.gemspec')
+Rake::GemPackageTask.new(spec) { }
+
+require 'rubygems/dependency_installer'
+desc 'Install hotcocoa'
+task :install => :gem do
+  Gem::Installer.new("pkg/#{spec.file_name}").install
+end
+
+# in reality this doesn't do the same dependency resolution that
+# bundler is capable of, but this should be good 99% of the time
+# and _way_ faster
+desc 'Setup dependencies without* Bundler'
+task :setup_dev do
+  (spec.runtime_dependencies + spec.development_dependencies).each do |dep|
+    Gem::DependencyInstaller.new.install(dep.name, dep.requirement)
+  end
+end
+
+desc 'Start up IRb with Hot Cocoa loaded'
+task :console do
+  irb = ENV['RUBY_VERSION'] ? 'irb' : 'macirb'
+  sh "#{irb} -Ilib -rhotcocoa"
+end
+
+begin
+  require 'yard'
+  YARD::Rake::YardocTask.new
+rescue LoadError
+  warn 'yard not available. Install it with: macgem install yard'
+end

data/bin/hotcocoa

@@ -2,30 +2,40 @@
 
 project_name = ARGV.shift
 
-if project_name.nil? or project_name == "--help" or project_name =="-h"
-  puts "Usage: hotcocoa <project name>"
+if project_name.nil? or project_name == '--help' or project_name == '-h'
+  puts 'Usage: hotcocoa <project name>'
+  exit
+end
+
+require 'rubygems'
+require 'hotcocoa/version'
+require 'hotcocoa/template'
+
+if project_name == '-v' or project_name == '--version'
+  puts "HotCocoa #{HotCocoa::VERSION} (#{RUBY_DESCRIPTION})"
   exit
 end
 
 if File.exist?(project_name)
-  if File.extname(project_name) == ".rb"
+  if File.extname(project_name) == '.rb'
     file_to_copy = project_name
-    project_name = project_name[0..-4]
+    project_name = project_name.chomp '.rb'
   else
-    puts %{Error: "#{project_name}" already exists in this directory.}
+    puts "Error: '#{project_name}' already exists in this directory."
     exit
   end
 else
   file_to_copy = nil
 end
 
-require 'hotcocoa/template'
-HotCocoa::Template.copy_to(project_name, project_name.split("_").collect(&:capitalize).join(" "))
+pretty_project_name = project_name.split(/[^a-zA-Z0-9]/).collect do |name|
+  name.sub(/./) { |character| character.upcase } 
+end.join
+HotCocoa::Template.new(project_name, pretty_project_name).copy!
 
 if file_to_copy
-  lib_dir     = File.join(project_name, "lib")
-  File.open(File.join(lib_dir, "application.rb"), "w") do |file|
+  lib_dir = File.join(project_name, 'lib')
+  File.open(File.join(lib_dir, 'application.rb'), 'w') do |file|
     file.write File.read(file_to_copy)
   end
 end
-

data/docs/Contributors.markdown

@@ -0,0 +1,25 @@
+# Contributors
+
+Hot Cocoa was originally developed as part of the MacRuby standard
+library; the project was led by Rich Kilmer and had contributions from
+the MacRuby core team and a few others.
+
+In late 2009, Hot Cocoa was pulled out of the MacRuby repository and
+moved to Github.
+
+## Credits
+
+* [Rich Kilmer](https://github.com/richkilmer)
+* [Laurent Sansonetti](https://github.com/lrz)
+* [Ben Stiglitz](https://github.com/benstiglitz)
+* [Eloy Durán](https://github.com/alloy)
+* [Vincent Isambart](https://github.com/vincentisambart)
+* [Dan Sinclair](https://github.com/dj2)
+* [Matt Aimonetti](https://github.com/mattetti)
+* [Isaac Kearse](https://github.com/isaac)
+* [reborg](https://github.com/reborg)
+* [Patrick](https://github.com/hellopatrick)
+* [Watson](https://github.com/watson1978)
+* [Mark Rada](https://github.com/ferrous26)
+
+If we forgot your name, let us know and we will add it.

data/docs/Mappings.markdown

@@ -0,0 +1,352 @@
+## Introduction
+
+A HotCocoa mapping defines a structure that sits on top of a
+particular Objective-C class and simplifies its usage in MacRuby.
+
+This structure is defined in a simple, Ruby-based
+[DSL](http://en.wikipedia.org/wiki/Domain-specific_language)
+(domain-specific language).  The HotCocoa DSL includes syntax to aid in
+object instantiation, constant mapping, default options, customized
+methods, and delegate-method mappings.  The only required section is
+object instantiation; the other four sections are only required if the
+Objective-C class in question requires it.  Once defined, a mapping is
+registered with the {#HotCocoa::Mappings} module, using the names of
+the mapping and the mapped Objective-C class.
+
+The mappings that ship with HotCocoa are found in the
+'lib/hotcocoa/mappings' directory of the source.  You can easily define
+your own mappings for classes by following the examples below.  Place
+mappings in files of your own, loading them after you load the
+`hotcocoa` library.
+
+## Basic Mapping Syntax
+
+The basic syntax for defining a mapping is:
+
+    HotCocoa::Mappings.map name: CocoaClassName do
+      # mapping code...
+    end
+
+To create a mapping, call the `map` method on `HotCocoa::Mappings`,
+passing in a key-value pair to specify the constructor name and Cocoa
+class to be mapped.  Replace `name:` with the desired name of the method
+you want to be generated and made available to users of HotCocoa.  For
+example, the mapping definition for an `NSButton` might be:
+
+    HotCocoa::Mappings.map button: NSButton do
+      # mapping code...
+    end
+
+This creates a method on HotCocoa named `button`, which will return
+an instance of an `NSButton` class.  One caveat to note now is that
+the class being mapped has to be available when you define the
+mapping. `NSButton` is available because HotCocoa loads the `Cocoa`
+framework; if you want to map a class from `AVFoundation` then you
+will need to load `AVFoundation` before you define any mappings.
+
+You can create more than one mapping per Objective-C class.  A good
+reason to do this would be to provide different sets of defaults. As
+an example,
+[Interface Builder](http://en.wikipedia.org/wiki/Interface_Builder)
+provides several "different" types of buttons in its Object Library,
+but they are all instances of `NSButton` that just have a different
+default configuration.
+
+## Object Instantiation Method (required)
+
+There are two methods, `#init_with_options` and `#alloc_with_options`,
+that you can implement to support object instantiation. Define these
+methods within the block that you pass to the `map` method.
+
+    HotCocoa::Mappings.map button: NSButton do
+      def init_with_options buttons, options
+        button.initWithFrame options.delete(:frame)
+      end
+    end
+
+As you can see from the method definition above, the
+`#init_with_options` method is provided with an instance of the class
+that you declared in the mapping (`NSButton`) which is created with
+`NSButton.alloc`. This implementation just calls the proper `#init`
+method. This example calls `#initWithFrame` and passes the options
+value for the `:frame`. The options hash is passed to this function
+when you call the `#button` method:
+
+    button frame: [0,0,20,100]
+
+Note that the method must delete any option that it consumes and must
+return the mapped object. Every option used in the construction of the
+object should be removed from the hash. Any options that are left in the hash
+after begin processed by the instantiation methods will be dispatched
+to the `NSButton` instance.
+
+The second method you can implement is:
+
+    HotCocoa::Mappings.map button: NSButton do
+      def alloc_with_options options
+        NSButton.alloc.initWithFrame options.delete(:frame)
+      end
+    end
+
+Here you are not provided with the `alloc`'d object as the first
+parameter, but simply the options hash. This is helpful for classes
+that use class methods for instantiation, such as:
+
+    NSImage.imageNamed 'my_image'
+
+You should implement either `#init_with_options` or
+`#alloc_with_options`, but not both. If `#alloc_with_options` exists,
+it will be called and `#init_with_options` will be ignored.
+
+If you want a constructor to handle a block with extra behavior then
+you will also need to implement `#handle_block` for the mapping. Block
+handling is done after the mapped instance has been initialized and
+`#handle_block` will be given the instance as a parameter. For
+instance, HotCocoa uses this construct to encapsulate normal
+application setup:
+
+    HotCocoa::Mappings.map application: NSApplication do
+      def alloc_with_options opts
+        NSApplication.sharedApplication
+      end
+      def handle_block app
+        load_menus
+        yield application
+        application.run
+      end
+    end
+
+    HotCocoa.application do |app|
+      app.delegate = self
+    end
+
+## Default Options (optional)
+
+You can provide a hash of default options in the definition of your
+mapping. This is very useful for many Cocoa classes, because there are
+so many configuration options. Defaults are appended to the options
+hash that is passed into the constructor method if a value of the same
+key does not exist.
+
+Supplying your defaults is simple. In the example below, if you
+provide a `:frame`, it will be used instead of `CGRectZero`:
+
+    HotCocoa::Mappings.map button: NSButton do
+      defaults bezel: :rounded,
+               frame: CGRectZero,
+              layout: {}
+    end
+
+A few of the defaults shown above are pretty important to UI classes;
+specifically, `:frame` and `:layout`. The `NSButton` example uses
+`frame: CGRectZero`. The `CGRectZero` constant equals a rectangle of
+`[0,0,0,0]`. The `layout: {}` part is important for using the
+`layout_view` classes, which are included in HotCocoa, it describes
+where to put the UI element.
+
+This default value for the layout is an empty hash, but if it's not
+passed, the default value  for the layout is actually `nil`. If the
+layout is `nil`, the component is not included when the `layout_view`
+computes the layout for the components. All of the UI mappings that ship with
+HotCocoa provide an empty hash as a default `:layout`.
+
+## Constant Mapping (optional, inherited)
+
+Because constant names need to be globally unique in Objective-C, they
+can get very long. What the constant mapping provides in HotCocoa is
+the ability to use short symbol names and map them to the constant
+names that are scoped to the wrapped class. This is an example of
+mapping constants to represent button state:
+
+    HotCocoa::Mappings.map button: NSButton do
+      constant :state, {
+        on:    NSOnState,
+        off:   NSOffState,
+        mixed: NSMixedState
+      }
+    end
+
+A constant map includes the key (`:state`), followed by a hash which
+maps symbols to actual constants. When you provide options to the
+constructor method that match a constant key, it looks up the
+corresponding value in that hash and replaces the value in the option
+hash with the constant's value.
+
+So, when you call:
+
+    button :state => :on
+
+It will be replaced with:
+
+    button :state => NSOnState
+
+You can have as many constant maps in each class as you need. Constant
+maps are also inherited by subclasses. A constant map on `NSView` is
+also available on `NSControl` and `NSButton` (as they are subclasses).
+
+If you provide a value for a constant key that is an array rather than
+a single symbol, the constants in the array are __OR__'d with each
+other. This is useful when the constants are masked. For `NSWindow`'s
+mapping of style:
+
+    { style: [:titled, :closable, :miniaturizable, :resizable] }
+
+is equivalent to:
+
+    style = NSTitledWindowMask         |
+            NSClosableWindowMask       |
+            NSMiniaturizableWindowMask |
+            NSResizableWindowMask
+
+## Custom Methods (optional, inherited)
+
+Custom methods are simply modules that are included in the instance;
+they provide idiomatic Ruby methods for the mapped Objective-C class
+instance. Providing custom methods in your mapping is easy:
+
+    HotCocoa::Mappings.map button: NSButton do
+      custom_methods do
+        def bezel= value
+          setBezelStyle(value)
+        end
+        def on?
+          state == NSOnState
+        end
+      end
+    end
+
+In the first method, `#bezel=`, we provide a better method name than
+`setBezelStyle`. Although we could provide idiomatic Ruby methods for
+every Objective-C method, the number of these methods is huge. The
+general principle is to customize where this provides something
+better, not just syntactically better. Custom methods, like constant
+mappings, are inherited by subclasses.
+
+## Constant Mappings and Custom Methods
+
+In the last example, the `#bezel=` method serves as a corresponding
+method name to the constant map for bezel style:
+
+    constant :bezel, {
+      rounded:            NSRoundedBezelStyle,
+      regular_square:     NSRegularSquareBezelStyle,
+      thick_square:       NSThickSquareBezelStyle,
+      thicker_square:     NSThickerSquareBezelStyle,
+      disclosure:         NSDisclosureBezelStyle,
+      shadowless_square:  NSShadowlessSquareBezelStyle,
+      circular:           NSCircularBezelStyle,
+      textured_square:    NSTexturedSquareBezelStyle,
+      help_button:        NSHelpButtonBezelStyle,
+      small_square:       NSSmallSquareBezelStyle,
+      textured_rounded:   NSTexturedRoundedBezelStyle,
+      round_rect:         NSRoundRectBezelStyle,
+      recessed:           NSRecessedBezelStyle,
+      rounded_disclosure: NSRoundedDisclosureBezelStyle
+    }
+
+This way, you can easily create buttons of the provided bezel style:
+
+    button :bezel => :circular
+
+If you recall from the default options section (above), you can also
+include default values that are constant mapped values (e.g.
+`:bezel => :rounded` is the default for a button). In this way,
+constant mappings and custom methods work together to provide a vastly
+better syntax for using constants in your code and simplifying the
+code needed for an `#init_with_options` method.
+
+## Delegate Method Mapping (optional)
+
+Delegate method mapping is a little more complex then the prior
+sections. Delegate methods are used pervasively in Cocoa to facilitate
+customization of controls. Normally, what you need to do is implement
+the methods that the control is looking for in a class of your
+own. You would then set an instance of that class as the delegate of
+the control, using `setDelegate(instance)`.
+
+In HotCocoa, we wanted to enable the use of Ruby blocks for delegate
+method calls, so the Objective-C code:
+
+    class MyDelegate
+      def windowWillClose sender
+        # perform something
+      end
+    end
+
+    window.setDelegate(MyDelegate.new)
+
+is simplified to the Ruby code:
+
+    window.will_close do
+      # perform something
+    end
+
+Notice that we do not have to worry about the `sender` parameter
+because the sender is `window`.
+
+To enable HotCocoa style delegation, you map individual delegate
+methods to a symbol name, then map parameters that are passed to that
+delegate method to the block parameters. For `NSWindow` the definition
+for delegating `windowWillClose`, which passes no parameters to the
+block, would be:
+
+    HotCocoa::Mappings.map window: NSWindow do
+      delegating 'windowWillClose:', to: :will_close
+    end
+
+This creates a `#will_close` method that accepts the block (as
+above). For the sake of efficiency, it:
+
+1. creates an object
+2. adds the delegating method (`#windowWillClose`) as a method on that
+   object's singleton class
+3. stores the passed-in block inside that object
+
+The generated `#windowWillClose` method calls that block when Cocoa
+calls the `#windowWillClose` method. Each time a delegate method is
+created, the object is set as the delegate (using `#setDelegate`).
+
+When a delegate needs to forward parameters to the block, the
+definition becomes a little more complex:
+
+    HotCocoa::Mappings.map window: NSWindow do
+      delegating 'window:willPositionSheet:usingRect:', to: :will_position_sheet, parameters: [:willPositionSheet, :usingRect]
+    end
+
+The `parameters:` list contains the corresponding selector name from
+the Objective-C selector. Even though the delegate method normally has
+three parameters (`window`, `willPositionSheet`, and `usingRect`), the
+block will only be passed the last two (because we already have the
+first parameter). Using this method would look like:
+
+    window.will_position_sheet do |sheet, rect|
+      # ...
+    end
+
+It's also possible to map a parameter, in cases where you have to
+invoke a more complex calling on the parameter:
+
+    HotCocoa::Mappings.map window: NSWindow do
+      delegating 'windowDidExpose:', to: :did_expose, parameters: ["windowDidExpose.userInfo['NSExposedRect']"]
+    end
+
+Here we want to walk the first parameter's `userInfo` dictionary, get
+the `NSExposedRect` rectangle, and pass it as a parameter to the
+`did_expose` block.  Using this method would look like:
+
+    window.did_expose do | rect|
+      # ...
+    end
+
+Each method for a delegate has to be mapped with an individual
+delegating call.
+
+## When To Make A Mapping
+
+The best candidates for a new HotCocoa mappings are classes that
+require a lot of configuration. Though sometimes it is convenient to
+make a mapping just to take advantage of a mapping feature that
+HotCocoa provides, such as block-based delegation.
+
+If you have mappings that you would like to share, feel free to open a
+pull request on [Github](http://github.com/ferrous26/hotcocoa).

data/docs/MappingsExplained.markdown

@@ -0,0 +1,22 @@
+# Mappings
+
+Hot Cocoa mappings are the centre piece of the library; they allow for
+instantiation and configuration of Cocoa classes using much more
+concise syntax than their native interface.
+
+There are two ways to use a mapping---either by including the Hot
+Cocoa behaviours or by extending them. This is a natural extension of
+Ruby's ability to `#include` and `#extend`.
+
+To include the behaviours, you would subclass an Objective-C class and
+then `#include` {HotCocoa::Behaviors}.
+
+To `#extend` and instance of an Objective-C class, you would just use
+the HotCocoa constructors.
+
+{file:docs/NewMappings.markdown New Mappings} can be added
+for any Objective-C class, in fact, you can create a mapping for any
+class, even your own.
+
+Mappings are organized by the framework to which they belong. This is
+so that they are not loaded until the framework they belong to is loaded.

data/docs/Overview.markdown

@@ -0,0 +1,58 @@
+# Overview
+
+If you've done any amount of programming on Mac OS X, you know that
+the API can be quite verbose. Even with MacRuby's wonderful keyword
+arguments, it can be daunting to enter this...
+
+    win = NSWindow.alloc.initWithContentRect [10,20,300,300],
+      styleMask: (NSTitledWindowMask         |
+                  NSClosableWindowMask       |
+                  NSMiniaturizableWindowMask |
+                  NSResizableWindowMask)
+
+...every time you want to create and configure a new `NSWindow` instance!
+
+This is the reason most developers use [Interface Builder](http://en.wikipedia.org/wiki/Interface_Builder)
+to configure interface components.
+The purpose of HotCocoa is to allow you to use the flexible syntax of
+Ruby and its dynamic nature to simplify programmatically constructing
+user interfaces on Mac OS X without an Interface Builder.
+
+With HotCocoa, creating the `NSWindow` instance above is as simple as:
+
+    win = window frame: [10,20,300,300]
+
+HotCocoa achieves this feat by creating Mappings over the most common
+Classes and Constants used on Mac OS X. Those mappings create
+constructor methods on the HotCocoa module (like the "window" method
+above). Each constructor method accepts an optional block which yields
+the created instance (more on that in the
+{file:docs/Tutorial.markdown HotCocoa Tutorial}). Mappings also
+decorate the standard Objective-C API with nice Ruby APIs for
+common operations. The important thing to realize is that the
+constructor methods return real instances of these common classes, not
+high-level abstractions. So, you can call any Objective-C method
+available on those objects.
+
+In HotCocoa, Mappings provide the following:
+
+* Defaults: Smart default constructor parameters (like the styles in
+  window) to minimize the parameters you have to pass in.
+* Constants: Mapping of constants to Ruby symbols to minimize the text
+  and maximize the readability of HotCocoa applications.
+* Constructors: Building the instances of the mapped classes using the
+  correct class-specific APIs.
+* Custom Methods: Ruby-friendly API for commonly used methods (like
+  `#<<` for `#addSubview` on `NSView` subclasses).
+* Delegate Methods: Simplified Ruby-friendly methods for delegating
+  instances that use Ruby blocks
+
+Now that you understand the basics of what HotCocoa is and why we are
+building it, please look at
+{file:docs/Resources.markdown HotCocoa Resources} (and eventually, the
+{file:docs/Tutorial.markdown HotCocoa Tutorial}) for examples of how
+to build Mac OS X applications with it. For a more detailed
+understanding of how to read, create, edit, or contribute mapping
+files, see {file:docs/Mappings.markdown HotCocoa Mappings}. For the
+current status of the project, visit the
+[code repository](http://github.com/ferrous26/hotcocoa) on Github.