[MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 64

Martin Kay mjkay at stanford.edu
Wed Dec 30 11:07:42 PST 2009


> Message: 2
> Date: Wed, 30 Dec 2009 13:09:54 -0500
> From: Matt Aimonetti <mattaimonetti at gmail.com>
> To: "MacRuby development discussions."
> 	<macruby-devel at lists.macosforge.org>
> Subject: Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 62
> Message-ID:
> 	<20fefa50912301009u6808d6ffmf6e67625301a48a5 at 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



More information about the MacRuby-devel mailing list