Opened 12 years ago

Last modified 10 years ago

#37 new task

Document Cocoa programming in OpenMCL

Reported by: gz Owned by: gb
Priority: normal Milestone: Cocoa IDE v?
Component: Documentation Version:
Keywords: funded Cc:

Description

--On July 29, 2007 11:25:01 PM -0600 Gary Byers <gb@…> wrote

I think that good tutorial material would include:

  • Apple's introduction to Cocoa:

<http://developer.apple.com/referencelibrary/GettingStarted/GS_Cocoa/index.html>

There's not a whole lot there that's overly ObjC specific, I don't think. I think that some understanding of basic Cocoa-specific concepts (like "delegate" objects and the notification mechanism) is necessary and/or desirable, and unless/until Lisp and ObjC GCs learn to peacefully coexist it's necessary to understand at least enough about retain/release/autorelease to know whether and when you got bit by them.

  • some information (scattered in release notes, email messages, source code

comments ...) that explains how Cocoa is integrated into CLOS and OpenMCL (ObjC classes are CLOS classes, "messages" are sort of like generic functions that dispatch on the class of their first argument and might someday be real GFs, name translation, MAKE-INSTANCE ...)

  • there are hundreds of documented Cocoa classes and thousands of

documented messages. A truly and totally minimal application is (nearly):

(#/run (make-instance 'ns:ns-application)) ; assuming that the main

bundle's set up properly

but a real application has menus (which have some mixture of generic and application-specific "action"s associated with them) and specializes at least generic classes (NSDocument, NSView, NSWindow) and defines application-specific behavior for those classes (sometimes) and their instances (most times.) It's often (not always) desirable to use Interface Builder to create application-specific UI elements and specify their behavior (e.g., what specific objects should be the targets of action messages ? What instance variable in the "owner" of a NSDocument class should be set to the unarchived instance instantiated by the nib ?)

Creating simple applications is ... simpler than creating complex ones. It is also generally true that very useful (though "simple") Cocoa applications usually require relatively little in the way of specialization of the stuff that you get for free.

Apple use a simple "Currency Converter" application as a tutorial: <http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/index.html>. Parts of this would be easy to translate into an OpenMCL-centric tutorial (the actual code); other parts ("create a project") are maybe easier to translate into something Bosco-specific than something IDE-specific (what's a project, exactly ? Is it a set of files that'll be built by some external batch compilation process ? Presumably not, but we may need to think about what it means to "start a project" or to "switch between projects" in an IDE that enabled you to do that.)

The actual code for something like CurrencyConverter? is trivial, and that code would certainly be a part of any "IDE for Cocoa application development".

Change History (3)

comment:1 Changed 11 years ago by rme

  • Keywords funded added
  • Milestone set to Cocoa IDE Improvements

The obj-c chapter in the manual needs to be updated to show the usage of the (#/someMethodName: obj arg) notation, and to note that the (ccl:send obj "someSelector:" arg) notation is no longer the way to go.

comment:2 Changed 11 years ago by rme

  • Priority changed from major to normal

comment:3 Changed 10 years ago by rme

  • Milestone changed from Cocoa IDE Improvements to Cocoa IDE v?
Note: See TracTickets for help on using tickets.