The third installment in the Leopard Technology Series for Developers provides an overview of Leopard’s application technologies: Time Machine, iChat Theater, the Instant Message Framework, the Calendar Store, the Ruby and Python Cocoa bridges, the new Scripting Bridge, Core Animation and 64-bit GUIs.
Leopard’s Application Technologies Overview
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I can’t wait to use ruby/python in a cocoa application.
The power of a scripting langage with the gui of a cocoa application: those bridges open so much possibilities in the system programming area =)
You can do that today already
http://pyobjc.sourceforge.net/
I was talking about a more interesting feature for me:
The ruby framework:
Framework
Why a framework? It’s easier for Mac development. It allows multiple versions, and lets you bundle Ruby inside your application. It’s also compatible with original layout /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Current/bin/ruby
http://blog.nicksieger.com/articles/2006/10/21/rubyconf-mac-os-x-an…
I am amazed and impressed just how much Apple is getting done under the hood here. That new Cocoa feature for the Scripting Bridge looks awesome. Bring it on!
The article doesn’t provide that much detail about any of the technologies it discusses. Not too surprising at this stage of development I suppose.
Personally I’m interested in finding out more about how well Core Animation is integrated into the NSView heirarchy. What I’m hoping is that they’ve done a job as good as they had with Newton. To specify animations for showing and hiding views on Newton you’d simply set values in the view to specify the type of animation. This could be done at compile time in the view editor, with no code required, or if you really felt like it at run-time. This kind of thing should be possible with NSViews by setting values in Interface Builder.
Shame I don’t have any spare time/money or I’d be tinkering with this stuff already.
Just today, Laurent Sansonetti by Apple posted on the Ruby-Cocoa mailing list:
| Here is a quick status about the work that has been done in the apple
unstable branch:
|
| – C structures support
|
| Now C structures are automatically handled by the BridgeSupport files.
| RubyCocoa doesn’t hardcode any NSRect/NSSize/… information anymore,
| everything is now dynamic. This was the last change to do in order to
| have a completely metadata-driven RubyCocoa (e.g. no hardcoded
| information anymore, everything dynamic)
| […]
| At runtime RubyCocoa will analyze the encoding and create proxy
| classes, then do the conversion between Ruby and ObjC. It also
| generates accessors for the fields, and some basic methods like
| comparison and constructor.
|
|
| – CoreFoundation types support
|
| CFTypes are also supported by BridgeSupport. This means that RubyCocoa
| is able to use the ObjC toll-free bridged classes, or create proxy
| classes when necessary. RubyCocoa also maintain the retain count of
| returned CF objects for you, like real Objective-C objects.
|
|
| – New supported frameworks
|
| Along with Foundation and AppKit, the following frameworks are now
| supported:
|
| CoreFoundation
| CoreGraphics
| WebKit.
(http://lists.sourceforge.jp/mailman/archives/rubycocoa-devel/2006-D…)