Exploring the Mac OS X Object System

Philippe writes "F-Script is an integrated set of tools that makes it possible to interactively explore and manipulate Cocoa objects as well as script them using new high-level programming techniques. This new article, Exploring Cocoa with F-Script, shows you how to use some of its most impressive features and demonstrates how it can be a useful addition to your developer toolkit."

PyObjC?

[Fiznarp]

I've seen Cocoa scripted with PyObjC [apple.com] and python Cocoa bindings.

Apple currently employs one of the maintainers of PyObjC.

Would someone informed care to explain if/when F-Script would be a better choice?

Re:How many?

[ceoyoyo]

Take a look at Python and PyObjC. http://pyobjc.sourceforge.net/ [sourceforge.net]

Re:How many?

[sqlrob]

Hasn't apple stated that they aren't adding any of the new APIs to java?

Re:PyObjC?

[timmy_mc]

F-script enables you to send messages to entire collections of objects at the same time. i.e. "> ArrayOfThings value" fires a value message to the array causing each object within the array responds to the message however it see's fit. When you get collections of arrays of objects takking to each other clever things can happen... http://www.fscript.org/documentation/OOPAL.pdf [fscript.org] tim

Re:PyObjC?

[Anonymous Coward]

F-Script can be attached to a running application. F-Script has been around since NextStep and before Python existed. Any other questions?

Re:How many?

[quadelirus]

If you mean development frameworks then Cocoa is the way to go. Carbon is older and mostly included for backwards compatibility. Cocoa is the new hotness. As far as IDE's go, I use XCode2 and InterfaceBuilder. They are easy to use once you know where things are. I wish they had some sort of tabbed editor and I would reccomend dual monitors while developing due to the number of windows you will have open, but other than that it is a great product.

A couple of notes:

I, like you, come from a Java background and have recently begun to write native Mac apps. I use XCode and InterfaceBuilder and they work together really well to write Cocoa apps very quickly. I decided to learn Objective-C because for some reason I thought it would be idea to know yet another language, but Java-Cocoa should work just as well.

I'm not sure if this is the same for Java-Cocoa, but in Objective-C/Cocoa the hardest thing for me to get used to was the graphical nature of the programming. In many languages you have API's that allow you to do things like Hello World programs and/or more complex programs like a simple browser without writing a line of code. You design the interface graphically and hit run and it works. The difference between most of those (for isntance JBuilder) and Cocoa development is that in JBuilder, even if you don't physically write the interface code, it gets coded to your class file as standard Java code. In cocoa this isn't the case. The interface is housed in a file called a NIB file. Your average programmer will probably not ever have to look directly at the contents of a NIB. Also connections between classes is created graphically. For instance, if you want to have a button do something when it is clicked you don't add an onclick listener anywhere in the code. Instead you have a special type of method in your controller class that handles actions and then in interface builder you control click on the button and drag it to the instance of your class and tell it to connect to the action. AFAIK, this MUST be done graphically. It can't be coded. Or at least, it is strongly discouraged. This graphical nature took me quite awhile to get used to.

Tabbed editor

[Jord]

Just an FYI, you can get the same functionality as a tabbed editor in XCode by setting the editor to use only one window. Double click on a file in XCode, then on the right side of the toolbar is a button which will change the editor mode and open all of the editors in one window. Then you can use Control-1 to switch between editors.

Not sure if you were aware of that feature.

Cocoa MVS bindings

[Fnord666]

AFAIK, this MUST be done graphically. It can't be coded. Or at least, it is strongly discouraged. This graphical nature took me quite awhile to get used to.

InterfaceBuilder makes the bindings in the MVC architecture for you when you connect them graphically. Once you get the hang of which object creates the event and which object should receive it then this becomes very straightforward. That being said, you can code by hand if you wish. I don't have the reference on me, but I believe the Hillegass book
"Cocoa(R) Programming for Mac(R) OS X (2nd Edition)" demonstrates coding an example application this way.

Re:How many?

[aledwards20]

"AFAIK, this MUST be done graphically. It can't be coded. Or at least, it is strongly discouraged. This graphical nature took me quite awhile to get used to."
This can be done through code. use the setAction:(SEL)aSelector and setTarget:(id)target methods. setTarget tells the button which object to talk to setAction tells the button what you want to say to the object.
ex:
defined in header
IBOutlet NSButton *myButton;

in some function in source file
[myButton setTarget: self]; //or any other object
[myButton setAction: @selector(toggleLines:)];

where toggle lines looks like
-(void) toggleLines: (id)button

Re:PyObjC?

[Bastian]

I've been using F-Script for a while now; it's solid, it plays very nicely with Cocoa, and includes a lot of nice time-saving syntactic sugar. Its syntax is also simple enough that I can use it for an application scripting language that users can pick up in a few minutes. The F-Script pallette for IB is also rather convenient; it means I can throw a debugging (or scripting) console into any app of mine with almost zero effort.

I don't really care if an Apple employee is working on one but not the other; F-Script is mature enough that it's not like I need to be afraid that the project will be orphaned before it's completed or anything like that. Nor do I care if Apple has blessed PyObjC or not. Apple also put scads of time and money into what I had always heard was a rather hacked Cocoa-Java bridge, only to essentially orphan it a year ago. And dare I mention AppleScript?

I haven't tried PyObjC, so I can't tell you if F-Script is a better choice or not, all I know is that it's a good choice. So I'll turn the question around - what makes PyObjC a better choice?

Bzzt. Wrong.

[wandazulu]

Um...have you done any programming on the mac, AC? Carbon is the cleaned up legacy API of the pre-OSX days. The idea was that you wrote to Carbon when developing your OS9 app, and then it should pretty much run unmodified in OS X (presuming a recompile to make it OS X native lest your app fire up the classic layer).

In that regard, Carbon is meant to run on other platforms only if you consider OS9 another platform. I think you are thinking that Objective C is somehow a bastardized version of C. It's not; Objective C is the full C language with additional object-oriented components a la C++, but not to the extreme that C++ takes it. Plus, Objective C gives you run time typing, which C++ does not provide (static, compile-time typing). This makes it very easy to get information about objects and is the basis of the key-value system that runs most of Cocoa. Objective C is inspired by Smalltalk and uses a number of its concepts whilst C++ was influenced heavily on Simula2 (I'm pretty sure). Regardless, both can call strncpy(), malloc() etc. if you want.

If you want write truly cross-platform C, you write to the standard C API *only* and let the users get their input and output via stdin and stdout. Not very graphical, but hey, you want cross platform, right?

Re:How many?

[JulesLt]

Yes - due to lack of interest they have ceased development of the Java-Cocoa bridge. Of course I am sure that if there was a lot of interest, that decision would be reversed.

Where people have interest in particular technologies you'll certainly see JNI libraries appearing, but most Java development on the Mac is cross-platform so didn't use the Cocoa bridge. I would imagine that building on top of the Eclipse RCP will be a popular means for many Java developers to get a closer native feel.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:How many?

[JulesLt]

The main and obvious one is Cocoa. While NextStep was available on many platforms and GnuStep continues to be, Cocoa has advanced a long way since. For all practical purposes, Objective-C is pretty much a 'Mac-only' language.

Others that spring to mind :
WebObjects - was cross-platform for a while, and in a weird way still is (the run-time was C++, now Java, but the only way to get a licence is with OS X server, and the development tools are now Mac specific). Front-ends can be Java or Browser clients.

OSA - this is 'Open Scripting Architecture' - it is the framework for adding scripting languages to OS X. The main example is AppleScript, but Python and JavaScript (Late Night Software) are also available on top of OSA. Any application that is said to be 'AppleScriptable' is in fact exposed via the OSA, so this does make it a high-level development platform, useful for sticking applications together (obvious one is glueing together a BitTorrent client, video conversion software and iTunes to auto-convert files for a video ipod).

Quartz Composer - if you have Tiger development tools, fire this up. It's an interesting way to develop graphics components, which can then be used as plug-ins in apps that support them. Having looked at Motion, you can see how much Motion is simply a friendly UI over Quartz, while Composer is a much more raw version.

Widgets - Apple's Dashboard widgets allow a mix of technologies, but mostly Javascript. (You can have a Quartz based widget, and you can fire off OS commands from a widget too). Even has it's own IDE, separate to XCode - DashCode. Not officially out but easy to find online.

Unix shell scripting - obviously not Mac specific, but Darwin and OS X do have unique commands - i.e. you CAN use them for Mac-specific development.

Odd proprietary languages : FutureBASIC is still hanging in there, as a Mac only version of BASIC. (RealBASIC is cross-platform and now-OO). I've certainly seen reviews of other similar tools, like a 3D-games writing language, but they are not things I tend to keep in mind. Took me a bit of Googling to even find the name of FutureBASIC.

If you want a direction to go in, I would suggest Obj-C and Cocoa. If you want to get better closer to the native layer than you can with Java it's definitely the way to go.
One observation : There appear to be a growing number of apps that just use WebKit to throw up a browser window and then use HTML/JavaScript for the actual application code. Each to their own - I guess it makes sense if you mostly have web development skills.