Hi Martin, You are bringing a good point. One can certainly write Cocoa apps without Xcode, it's far from a requirement. I used to have a small section in the book that was showing you how to create a UI with Interface Builder, load the Address People Picker view widget, simulate the UI and save it as a nib called 'picker.nib' (xib files have to be compiled). You can then open vim, textmate or whatever editor you fancy, and type the following code: framework 'Cocoa' framework 'AddressBook' app = NSApplication.sharedApplication controller = NSWindowController.alloc.initWithWindowNibPath(File.expand_path('picker.nib'), owner:self) controller.window app.run Save the file in the same directly than your nib file and launch the script: $ macruby picker.rb (you can also compile the file using macrubyc) You will notice that the UI launches and seems to work fine until you try to type some text in the text input box. (the text will show in the terminal and not the UI) Really, what you want is to create a .app and everything will be fine, but doing that manually isn't really straight forward. Also, having to bind UI elements with classes, actions and outlet is a pain if you don't use Xcode. At the end of the day, or we have something like HotCocoa/Rucola which works fine and can be an alternative to Xcode, or every time you will want to write a Cocoa app, you will rely on Xcode. I still hope that Rich and Eloy will be able to finish their tools on time so I can have a section on Xcode alternatives, but to start with, I think it's better to show the "standard" way to write Cocoa apps in MacRuby, and that means using Xcode. I'm also planning on having a section on apps without an UI and for that, we won't need Xcode. I hope that makes sense, thanks for your feedback. - Matt On Wed, Dec 30, 2009 at 12:40 PM, Martin Kay <mjkay@stanford.edu> wrote:
I look forward to your book with impatience. From the other stuff I have seen of yours, I expect that it will be both informative and literate.
May I put in a plea, hopefully before it is too late? Could you please either make mastery of xcode optional---which I would prefer---or provide a mental model for it that makes it coherent? Every purported introduction attempts to lead me by the hand through a morass of totally unmotivated complexity while expecting me to be grateful for how it is simplifying my life. It would be a great pity if the elegance of Macruby could only be appreciated after hacking ones way through miles of xcode underbrush.
--Martin Kay
On Dec 29, 2009, at 10:46 PM, macruby-devel-request@lists.macosforge.orgwrote:
Send MacRuby-devel mailing list submissions to macruby-devel@lists.macosforge.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel or, via email, send a message with subject or body 'help' to macruby-devel-request@lists.macosforge.org
You can reach the person managing the list at macruby-devel-owner@lists.macosforge.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of MacRuby-devel digest..."
Today's Topics:
1. Error Handling (Robert Rice) 2. Input field list (Robert Rice) 3. Re: Input field list (Steven Canfield) 4. Re: Input field list (Matt Aimonetti) 5. detect the language of a string (Matt Aimonetti) 6. Re: detect the language of a string (Conrad Taylor)
----------------------------------------------------------------------
Message: 1 Date: Tue, 29 Dec 2009 20:42:00 -0500 From: Robert Rice <rice.audio@pobox.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: [MacRuby-devel] Error Handling Message-ID: <22ADDFA8-03F6-4136-993C-26D3D7F47C80@pobox.com> Content-Type: text/plain; charset="us-ascii"
MacRuby is working out well for my application with the exception of error handling. I find that I cannot get a traceback of all errors even when I have a rescue pushed on the stack. Sending a message to an undefined class action causes a hang with no error message that I cannot recover from. Nor can I always get useful information from the "bt" command in GDB if GDB even remains running after the error.
Is there a way to trace actions calls from NSApplicationMain?
Thanks, Bob Rice