Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 64
Message: 2 Date: Wed, 30 Dec 2009 13:09:54 -0500 From: Matt Aimonetti <mattaimonetti@gmail.com> To: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Subject: Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 62 Message-ID: <20fefa50912301009u6808d6ffmf6e67625301a48a5@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
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
Matt, thank you for the swift reply. OK, so maybe we are stuck with Xcode. In that case, there has to be a mental model for what it, or the part of it we will be using in this part of the book. Here's what I think would work for me. Start with simple examples that do not require it, but that do go beyond the capabilities of vanilla ruby. Then motivate Xcode somewhat as you did in your message. Then---and here is the main point---explain what Xcode is and what those parts of it we are going to use are going to do for us. Then proceed with more advanced examples. The idea is, at all costs, to avoid "Now back in InterfaceBuilder, click on X and drag Y to Z..." all with no motivation. Programming is an enterprise in which we build complex structures out of simple parts by understanding clearly how the parts work and how the fit together. Magic has no place in there. Thank you for listening to may ravings! --Martin
On Dec 30, 2009, at 11:07 AM, Martin Kay wrote:
Programming is an enterprise in which we build complex structures out of simple parts by understanding clearly how the parts work and how the fit together. Magic has no place in there.
Ah, but if that were actually true in practice, a lot of consultants would be out of work. ;-) - Jordan
participants (2)
-
Jordan K. Hubbard
-
Martin Kay