[MacRuby-devel] Tutorials and Xcode
I see occasional references of tutorials on the list, and I look forward to their appearance with eagerness. But I fear that their usefulness may be be greatly reduced, as have so many in the past, by their attachment to XCode. I do not know whether XCode is a good or a bad thing for developers because it is totally beyond my comprehension. I do know that it gives rise to a "lead by the hand" style of tutorial from which it is difficult to learn anything. You know the kind of thing: "Click on this; type in that; drag this from here to there; click on that, and voilà!". But no attempt is made to provide a model form which one could understand this moves, or to produce a sequence of events that would achieve the result *I* have in mind. Examples are, or course, indispensible, so long as one can see what it is that they exemplify. Maybe someone could explain, as well as exemplify XCode or, alternatively, do MacRuby without it. --Martin ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 62
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-requ...@lists.macosforge.org wrote: > 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-requ...@lists.macosforge.org > > You can reach the person managing the list at > macruby-devel-ow...@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 > To: "MacRuby development discussions." > > Subject: [MacRuby-devel] Error Handling > Message-ID: <22addfa8-03f6-4136-993c-26d3d7f47...@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 > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20091229/570d90dd/attachment-0001.html> > > -- > > Message: 2 > Date: Wed, 30 Dec 2009 00:01:33 -0500 > From: Robert Rice > To: "MacRuby development discussions." > > Subject: [MacRuby-devel] Input field list > Message-ID: > Content-Type: text/plain; charset=us-ascii > > This is an unrelated Cocoa newbe question but I'm sure someone could help me. > > Is there a way to programmatically get a list of the input and control field > objects in a view rather than linking all of the fields separately in > Interface Builder? > > Thanks, > Bob Rice > > > > -- > > Message: 3 > Date: Tue, 29 Dec 2009 22:51:19 -0700 > From: Steven Canfield > To: "MacRuby development discussions." > > Cc: "MacRuby development discussions." > > Subject: Re: [MacRuby-devel] Input field list > Message-ID: <8475e755-d3bf-436f-9d98-1e72f48e8...@gmail.com> > Content-Type: text/plain; charset=us-ascii; format=flowed; > delsp=yes > > Get the views subviews and iterate on them by class name. - > isKindOfClass is the method. You could write filter / utility methods > to make this easier. > > Steve Canfield > > On Dec 29, 2009, at 10:01 PM, Robert Rice wrote: > >> This is an unrelated Cocoa newbe question but I'm sure someone could >> help me. >> >> Is there a way to programmatically get a list of the input and >> control field objects in a view rather than linking all of the >> fields separately in Interface Builder? >> >> Thanks, >> Bob Rice >> >> ___ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > -- > > Message: 4 > Date: Wed, 30 Dec 2009 01:08:47 -0500 &
Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 64
> Message: 2
> Date: Wed, 30 Dec 2009 13:09:54 -0500
> From: Matt Aimonetti
> To: "MacRuby development discussions."
>
> Subject: Re: [MacRuby-devel] MacRuby-devel Digest, Vol 22, Issue 62
> Message-ID:
> <20fefa50912301009u6808d6ffmf6e67625301a4...@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
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
