Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Exploring the Mac OS X Object System

Hemos posted more than 8 years ago | from the a-deep-look-into-it dept.

60

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."

cancel ×

60 comments

Sorry! There are no comments related to the filter you selected.

Do you love my penis? (-1, Troll)

(TK)Dessimat0r (668222) | more than 8 years ago | (#15605670)

Paedophile hunt police find human skull

AMERICAN police made further grim discoveries yesterday during their investigation into a paedophile network responsible for kidnapping girls.

A skull and bones were dug up at the home of the network's suspected ringleader, Rob Malda. It was feared that they were the remains of two teenagers who disappeared from New Orleans a year ago. The bones were unearthed after police spent six days digging at a house in Holland, Michigan, one of six properties owned by Malda.

On a visit to the house last week, Malda told police that his accomplice, Jeff Bates, had buried five bodies under a shed. Maximillion Arturo, a police spokesman in Michigan, said that no further statement would be made until families had been informed.

There was speculation last night that the remains are those of shemales from the GNAA. Malda has admitted abducting them. However, he earlier told police that he believed the two girls were still alive and being held somewhere outside Michigan.

Two eight-year-old girls abducted by Malda have been found buried at another of his properties. They starved to death while he was in prison on a theft charge. Malda's wife, Kathleen Malda, has told police that she was supposed to feed the children while her husband was in prison, but was too frightened to enter their cell.

Another two girls were found alive by police two days after Malda's arrest on Aug 13. Ten people, including Malda, his wife and an American police officer, are in custody in connection with the case.

The raped corpses of two women and parts of a third body have been discovered in a freezer at the Slashdot headquarters, along with the remains of an 80 year old woman that remain unidentified.

TrollKore - At the head of the game.
I hate you, I hate your country, and I hate your face.

Re:Do you love my penis? (0)

Anonymous Coward | more than 8 years ago | (#15625077)

ugh, I can't believe Rob Malda would do such a thing. I guess that's what happens when you no longer matter.

PyObjC? (5, Informative)

Fiznarp (233) | more than 8 years ago | (#15605723)

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:PyObjC? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15605790)

The really big push will come with the switch to Mac OS W in January. Already, internally at Apple, they've gotten most of the object APIs Windows programmers take for granted talking seamlessly with Apple's Cocoa and Carbon systems. Amazingly, Objective C is a perfect fit with VBScript, with the named, variadic, parameters of each coupled with their underlying object oriented models working better than the equivalents with Java and C#. PyObjC was a good idea at the time, but VBScript looks set to revolutionize the Macintosh environment.

Note: the following is from an Apple insider who was there when the meeting took place:

The board meeting

So it's Tuesday morning at Apple. The boardroom is having another meeting about the future of the Macintosh. They're perusing the feedback over the unofficial port of Windows to the Mac, and considering the consequences. There's a whole bunch of things on the agenda. OS development is hard, and it's expensive. Their competitors, Sony and Lenevo, doesn't need to do it, and they're doing pretty well all in all. Plus, there's the whole break up plan. When Apple separates into Apple Macintosh Inc and iTunes Corp, how attractive will Apple Macintosh be as a take-over target? The whole move to Intel will be for naught if it hasn't made Dell and friends just a little more excited and comfortable they could fit the Macintosh into their lines.

Apple has some little development projects on the boil and has for some time. To begin with, it's pretty much completely reimplemented the Carbon APIs under Windows. Indeed, that's how iTunes and Quicktime are implemented. But, interestingly, so are the Cocoa APIs. They're all there, Apple never stopped developing them, even after it nixed WebObjects for that platform. It's also in need of certain features that would help it with the future. Apple has no "managed code" environment - it supported Java to a certain extent, but Cocoa never was a perfect fit for that. Apple's progress with .NET, unofficially, under Windows and OS X, is coming along surprisingly well.

As time has gone on, the notion of switching to Windows as the base platform really has gotten more and more plausable. There are still roadblocks, Apple needs Microsoft to provide them with a little more customizability of the UI. A switch to Windows without providing the essential Macintosh experience just wouldn't do. But, well, .NET, and Aero, are Microsoft's attempts to break with the past. Perhaps an OS built upon these APIs could, with Microsoft's help, look entirely like a Mac environment - with the right code, obviously. You don't want a Dell user flipping a registry switch and getting a Mac.

It's clear that whatever happens, OS X is doomed. Postings by MacRumors alumni arguing that the porting of Windows to the Mac spells disaster are read out, and largely agreed with. But the question then is - does Apple continue to pour money into OS X, or could Gates and Ballmer be ameanable to making the modifications needed to make Windows Vista the next Macintosh OS?

The phone call

Jobs picks up the phone and calls Gates. There's a brief discussion, and then the phone's put down. A few minutes later, the phone rings. It's Ballmer, Gates, and Allchin.

"We think we can do it, Steve" says Bill Gates. "I mean, this is a major thing for us. It's a coup, and I know you know we're thinking it. So we're going to help in any way we can."

Allchin interjects: "Funnily enough, from our end, the code's largely there. We need a bit more time. WinFS needs some work - we'd put it on hold, but if you're going to want Spotlight on this OS, we'll need to finish it. Sticking menus at the top of the screen and reordering them... that's easy stuff. We'd appreciate it if you ported your own Dock and Finder, you can keep that proprietary if you want."

Jobs smiles. "That's perfect for us. Means we keep control over the so-called Macintosh experience. That's really the only reason we've stuck with our own operating systems for so long."

Ballmer speaks next. "Well, I'm looking at the timings, we can probably get things to you in a service pack for Vista, perhaps in April or May of 2007?"

"January", says Jobs. "It's got to be January. I want to go to MacWorld, and announce a new operating system, Mac OS W, that brings the best of the Mac, and the best of Microsoft. And I want to tell people "It's shipping today.", it's important, for our credibility and everything."

There's silence on the other end. Allchin chirps up next.

"Y'know. Y'know, it really is possible. Let's forget about the November release date. Let's go full steam ahead, and time the release for January. An early release is just going to trip us up."

"I have to agree with Jim there", says Gates. "It's not going to be pretty, but we can do this if we delay the OS. Especially if a lot of this stuff's done, or you're going to do it, and all we have to do is add a few missing features like WinFS. About time we implemented that anyway."

Ballmer sighs. "Ok Steve. Our people will talk to your people. January it is. I'm going to announce the delay right now, no use keeping this a secret. The delay, that is."

The conversation continues constructively, and the phone is hung up.

"They're good people, at Microsoft, I mean" says Jobs. There are nods and mutters of agreement from the others present. "I think this is a great partnership. It's going to be great for Apple. Great for our customers, I think. No more incompabilities. Things are going to "just work". Strange, somehow, that Microsoft would be giving us the last piece to make the Macintosh the computer for the rest of us."

Postscript

Apple's user interface technology has always been a cut above the rest, earning grudging respect from Open Source and Microsoft developers alike. Finally, with Quartz ported over the stable and powerful and secure (it was only the user land that made NT/XP insecure) NT kernel, there will be an operating system that virtually everyone will like. This is finally the best of all worlds, the excellence of Apple UI design married to the most advanced popular commercial operating system we have. There will be interoperability, there will be security, and there will be power. This represents, to some extent, the end of operating system development, one operating system, combining the best of Apple and the best of Microsoft. A new improved computing model to take us into the future.

Re:PyObjC? (0)

Anonymous Coward | more than 8 years ago | (#15606154)

Gee.. I have seen this before. How many times is this going to be posted on Slashdot. Get original. Here's on from OSNews here [osviews.com] . How long have you been waiting to post this?

Re:PyObjC? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15607171)

Quit the conspiracy BS. Obviously that guy has the same source I do.

I think Mac OS W is, quite honestly, going to revolutionize computing. We're going to see things that the .NET CLR and Java systems could only dream of doing. Proper, interoperable, object orientation, the type only dreamed of since the days of SmallTalk. Language independence. API independence. A GUI that, in many ways, was built for Windows and always felt uncomfortable grafted on to a poor Unix clone like Darwin. It's the best of Microsoft, and the best of Apple. The way things should be. No more incompatibilities. Everything will, for the first time, "just work".

I can't see why you're not more excited.

Re:PyObjC? (0)

ceoyoyo (59147) | more than 8 years ago | (#15606205)

That was my first (and last) impression too. F-Script looks like it has a nice object browser, but why didn't they write it in Python and have all the hard work done for them?

Re:PyObjC? (5, Informative)

Anonymous Coward | more than 8 years ago | (#15606547)

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

Re:PyObjC? (1)

ceoyoyo (59147) | more than 8 years ago | (#15606752)

Python can also be attached to a running application, including one not designed to have Python attached to it.

I didn't know F-Script has been around that long. Interesting.

Re:PyObjC? (2, Interesting)

Bastian (66383) | more than 8 years ago | (#15610231)

F-Script can also be plugged into an app that wasn't designed to have it attached. From what I understand, PyInjector was created by following in the footsteps of FScriptAnywhere.

Re:PyObjC? (3, Informative)

timmy_mc (985097) | more than 8 years ago | (#15606522)

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? (1)

dushkin (965522) | more than 8 years ago | (#15606734)

Woo! Nice! I didn't know about that.

Re:PyObjC? (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15606787)

PyObjC is great for Python programmers who want to access Objective-C libraries. However, as a native scripting language for Objective-C/Cocoa, it is not optimal. First, you have two different object models to deal with (Python and Objective-C), which introduces some impedance mismatch and complexity. Second, the Python syntax for invoking methods does not fit well with Objective-C's keyword syntax for methods.

Re:PyObjC? (2, Insightful)

lisaparratt (752068) | more than 8 years ago | (#15607327)

Um, when one is a person who doesn't like Python, maybe? We do exist, you know.

Re:PyObjC? (4, Informative)

Bastian (66383) | more than 8 years ago | (#15608014)

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?

Re:PyObjC? (3, Informative)

jcr (53032) | more than 8 years ago | (#15608711)

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.

It's syntax is Smalltalk, which happens to map very well to Objective-C.

-jcr

Re:PyObjC? (4, Interesting)

Bastian (66383) | more than 8 years ago | (#15610210)

Right, which is a huge advantage of F-Script over what I've seen of PyObjC. The only major difference between passing a message in F-Script and passing one in ObjC is that I use parentheses instead of square brackets. PyObjC has to go through some rather unnatural contortions in order to do the same, and it kind of made the code hurt my eyes a little bit, and I could see where it could make reading others' code a bit confusing.

I'm also wondering, does PyObjC have "tab completion" for code the way the built-in F-Script console does? I've gotten really used to that in XCode; Python would have to be a damn sight better than F-Script for the switch to it to accelerate my coding more than the loss of Code Sense-style symbol completion would slow it down.

Re:PyObjC? (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15609820)

Nothing beats F-Script when it comes to exploring objects interactively. PyObjC does not have the kind of graphical tools shown in this article. My favorite feature is F-Script Anywhere, a tool for injecting F-Script into running applications.

Re:PyObjC? (0)

Anonymous Coward | more than 8 years ago | (#15611222)

I can envisage a boomerang effect http://tinyurl.com/sxelz [tinyurl.com]

The Future Of OS X (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15605729)

Apple will be partnering with Microsoft in a deal that will rock the computing world.

Microsoft will adopt the good parts of OS X and rebrand the system as Microsoft's own. Microsoft has a new from scratch OS they have been working on but it is nowhere near ready to save Microsoft from the Vista disaster. Microsoft needs something soon. OS X + virtualization is going to be the answer.

With Apple desktop marketshare continuing to slide lower, down to 2 percent now?, they want to focus on the high growth digital media side of the company. Jettisoning the going nowhere Intel Mac hardware line and pawning off OS X to Microsoft will allow them to lock up the digital media market because...

In exchange for OS X Apple will get from Microsoft the adoption of Apple's digital media APIs and formats.

Both companies will be effectively splitting up the computing world into two distinct areas of control just like certain superpowers did hundreds years ago with parts of the globe.

Cringely? (5, Funny)

Jerk City Troll (661616) | more than 8 years ago | (#15605742)

Is that you?

Re:The Future Of OS X (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15605865)

Four words:

In your dreams, kid.

Re:The Future Of OS X (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15606034)

"Four words:

In your dreams, kid."

Wait, wait!!!

Let me guess, your attempt at displaying Indignation comes from your belief that Apple is just about to 'explode in marketshare' now that they switched to Intel 'like you have been saying they should for years'

Bwhahahaha!!!

Sorry clown, Apple getting dumped by IBM signed the death warrant for Mac hardware. The computing world isn't waiting around to buy overpriced lemons from Apple. There is only one direction an overpriced x86 OEM is going in marketshare.

DOWN.

Re:The Future Of OS X (2, Insightful)

jcr (53032) | more than 8 years ago | (#15608767)

Are you the same AC that was trolling this on Digg.com?

Sure, MS needs to do something smarter than repeat the Longhorn disaster, but I really doubt that BG and Monkey-boy have the guts to admit that they can't ship a major revision to their OS anymore.

-jcr

How many? (5, Interesting)

andrewman327 (635952) | more than 8 years ago | (#15605740)

I was wondering how many Mac-specific development platforms are out there. Obviously there are loads of them for Windows, but how many just for Mac?

As much as this will get me flamed, I code in Java when I am writing applications for Mac. I find it works well enough, but I am interested in becoming a bit more versitile.

Re:How many? (2, Informative)

ceoyoyo (59147) | more than 8 years ago | (#15606228)

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

Re:How many? (1)

LnxAddct (679316) | more than 8 years ago | (#15606301)

Do you mean APIs and SDKs like Quicktime, CoreAudio, .Mac, etc..., or something else? Regardless, coding Mac apps in Java is usually fine considering how well Apple ties Java into everything.
Regards,
Steve

Re:How many? (2, Informative)

sqlrob (173498) | more than 8 years ago | (#15606362)

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

Re:How many? (3, Informative)

JulesLt (909417) | more than 8 years ago | (#15608492)

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.

Re:How many? (1)

Bastian (66383) | more than 8 years ago | (#15610253)

On top of that, the biggest objective benefit of developing Cocoa apps in Java was taken away with the addition of a garbage collector to the Objective-C runtime.

I suppose there's still the benefit of allowing people who already know Java to work with a familiar language, but of course OS X also provides Java developers with a set of APIs that should be much more familiar than Cocoa. In a sense, the Cocoa-Java bridge was always a solution in need of a problem.

Re:How many? (1)

toph42 (160730) | more than 8 years ago | (#15614036)

Just to clarify: Apple said they will not add new APIs to the Cocoa-Java Bridge. They will still support 100% Pure Java with the JRE, ongoing.

Re:How many? (5, Informative)

quadelirus (694946) | more than 8 years ago | (#15606609)

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.

Re:How many? (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15606993)

Carbon is older and mostly included for backwards compatibility.

Carbon is also the API of choice if you want to write things that also run on platforms other than the Macintosh. Carbon is your standard C API and is a fully capable first-class citizen in MacOS X. Besides it being much easier to make higher-performing software with Carbon, it uses a language understood by almost every engineer in the world.

When Apple moves Cocoa to something other than Objective C maybe they'll have a shot at getting more developers in their camp.

Bzzt. Wrong. (4, Informative)

wandazulu (265281) | more than 8 years ago | (#15608033)

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:Bzzt. Wrong. (2, Interesting)

spitzak (4019) | more than 8 years ago | (#15608718)

The original poster was talking about making portable GUI code. You cannot use Cocoa, because that basically means you are using a Mac-only toolkit (GNUStep(?) is the only attempt to fix this I know of, and it isn't anywhere close yet). You instead use the interface to some portable toolkit, all the ones that are Linux+Windows have or are working on OS/X versions. As far as I can tell they *all* use the Carbon API. You would think Cocoa could be used, at least to create a blank Cocoa window and draw the tookit's widgets inside it, but there seems to be significant overhead and complexity in using Cocoa, and excessive differences from X/Windows, so that Carbon is preferred.

So the original poster was exactly correct, you use Carbon if you want to port your program.

Re:Bzzt. Wrong. (0, Troll)

Viol8 (599362) | more than 8 years ago | (#15612778)

>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?

You're new to unix arn't you? He could use many of the X windows libraries that use a C API
which will then run on (probably) all versions of unix. Apple include an X windows layer
if you wish to use it instead of their wierd home-brew GUI system and Objective-C language
which no one apart from Mac users and a few ivory tower university types bother to waste
their time with.

Re:Bzzt. Wrong. (0)

Anonymous Coward | more than 8 years ago | (#15618383)

The parent isn't really a troll. I know I'll get flamed, but Objective-C is a weird thing, IMHO. When we were forced to to port our app to OSX because some sales guy used that as an excuse for not selling, we ported using Carbon. We examined using Objective-C and Cocoa, but the integration issues with our existing C++ codebase was ridiculous. Objective-C can't handle C++ exceptions, etc. etc. Bad things happen.

Carbon was much better. Our port wound up using the BSD layer as much as possible for the code code, and Carbon for the UI. It works pretty well, and is mostly the same as the Windows version. I'd love to have a sales guy claim they needed a Linux version! That'd be fun, and a lot easier, except for the audio...

2 years later, and our Mac sales are still 1% of our Windows sales... in the education market!

Posting anonymously to keep the zealots from killing my karma!

Tabbed editor (3, Informative)

Jord (547813) | more than 8 years ago | (#15607060)

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 (3, Informative)

Fnord666 (889225) | more than 8 years ago | (#15607280)

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? (3, Funny)

Cygfrydd (957180) | more than 8 years ago | (#15607527)

Java-Cocoa... this would be... mocha?

Re:How many? (1)

lahi (316099) | more than 8 years ago | (#15608921)

No. Wiener Melange.

Re:How many? (3, Informative)

aledwards20 (985127) | more than 8 years ago | (#15607922)

"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:How many? (1)

quadelirus (694946) | more than 8 years ago | (#15611820)

I figured there must be a way to do it but I didn't know how, thank you. When I started out in Cocoa programming all tutorials and books typically had you connecting things like that in the interface builder. Do you think programming graphically or by hand is better when dealing with Cocoa?

Re:How many? (1)

aledwards20 (985127) | more than 8 years ago | (#15612668)

With Cocoa, I strongly encourage using Interface Builder especially if you are learning. I typically only use Interface builder to build my UI so it retains the Aqua look and feel and make the GUI easier to maintain. You could do it all by hand if you wanted to, and there isn't any thing wrong with that. I have mixed using NIB with coding portions of the UI by hand and it works fine (personal projects). I haven't done a complete UI in code yet because you miss some of the benefits of Interface Builder and NIB files. Interface Builder creates all the objects for your GUI and serializes them in the NIB. Your app automatically reactivates the objects when its opened and connects objects to the appropriate targets and actions. This is wonderful for quickly creating apps that take full advantage of Cocoa controls and formatting because you don't have to write the code to initialize the UI and specify control behavior. Look in the object inspector to see all of what you can do without code. Coding by hand, you take on creating the GUI objects, initializing all the objects, connecting all the components, setting up the look and feel, etc. Try to create a NSButton by hand, it doesn't look like a Interface Builder NSButton at first. Also suppose the layout of the UI changes but you keep all the controls. If you code by hand you have to manually move all the components with code. In Interface Builder, just move the controls save the NIB and you are done, no change in code.

Re:How many? (1)

vistic (556838) | more than 8 years ago | (#15609612)

Apple has a good tutorial [apple.com] on their site for those who want to jump right in and figure it all out. I think you can do this with Java/Cocoa just by selecting Java as your project instead of ObjC.

I actually did this in ObjC and it all worked fine, then tried to go back and make it Java... and it was kind of odd how it worked with Java I thought. It seems for this kind of programming model and IDE, that Objective C is better suited.

Re:How many? (1)

squiggleslash (241428) | more than 8 years ago | (#15612066)

Not that it matters much, but Cocoa is arguably older than Carbon. Carbon dates back to the Windows port of Quicktime in the early nineties, where it started out as a compatibility library before becoming a more general purpose Mac OS-like API for Mac OS X. Cocoa, on the other hand, is simply the name given to the most recent revisions of the OpenStep API, dating back to NEXTSTEP in the late eighties.

Both APIs have equal access to the operating system. Apple's attempts to make Cocoa a little more language generic haven't been entirely successful, with the Java APIs deprecated. Carbon still seems to be largely C++ specific though I can see that if someone wanted to, they could make Carbon a little more available to other languages than it is now (the will is lacking, not the capability.) I guess you should make your choice on the basis of the language you want to use.

Re:How many? (1)

toph42 (160730) | more than 8 years ago | (#15614009)

Carbon is older and mostly included for backwards compatibility. Cocoa is the new hotness.

Just to clarify, Cocoa is not newer than Carbon. It was created for Mac OS X 1.0 as a way for traditional Toolbox applications (i.e. MacOS Classic apps) to be compiled to run natively in Mac OS X. Cocoa, however, is simply a new name for the API that NeXT computers used from 1985. Don't get me wrong. Cocoa is the new hotness, just because it's the first-class API for Mac OS X, getting the most love and care from Apple's engineers. Cocoa is what you want to use for new development. Carbon is just a way to shoehorn old code into a modern environment.

Re:How many? (2, Informative)

JulesLt (909417) | more than 8 years ago | (#15611177)

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.

First object to check out... (3, Funny)

Gattman01 (957859) | more than 8 years ago | (#15605764)

...is the trash can?

Or is that Vista I'm thinking of?

Re:First object to check out... (3, Funny)

Mad Marlin (96929) | more than 8 years ago | (#15606249)

Recycle bin: cuz MS is more eco-friendly.

Re:First object to check out... (1)

Gattman01 (957859) | more than 8 years ago | (#15606398)

1's grow on trees, but 0's are precious resource which need to protect.
If people other then Microsoft don't start doing the same thing, there won't be any 0's left for our great-grandchildren.

Won't someone please think of the children?

Re:First object to check out... (1)

FluffyWithTeeth (890188) | more than 8 years ago | (#15607542)

Heh, I actually fiddled with the settings so that my Trash is renamed, "INFERIOR!"

Man, I'm sad...

Looks nice... (1, Flamebait)

Ant P. (974313) | more than 8 years ago | (#15605851)

...but is giving everything access to everything else in this way safe?

Re:Looks nice... (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15605961)

That's was a pretty vague question, so I can only give a vague answer. In general Objective-C will favor power and flexibility over "security", and no classes or methods are truly private.

Re:Looks nice... (2, Funny)

Profane MuthaFucka (574406) | more than 8 years ago | (#15605976)

It's safe in one way - you can say "F-script" on TV without getting fined by the FCC.

Live Testing is Where F-Script Really Shines (3, Interesting)

krisamico (452786) | more than 8 years ago | (#15608236)

I have used F-Script to write tests for my applications for quite some time. In fact, pretty much everything I write has an F-Script console built into it when DEBUG is on. Naturally, OCUnit is nice for built-in unit test, but I really like being able to write an impromptu test into the F-Script console real quick to exercise some newly written or changed code. My clients often do not give me much time for writing enough built-in tests, so F-Script helps me pick up the slack with convenient, live testing. On the bad side, with F-Script, you are relegated to writing non-portable tests with odd, SmallTalky syntax, but for me it is an acceptable compromise for such a good, free (as in beer), on-the-fly testing tool. I don't remember having thanked Philippe for making it available. Thanks, Philippe!

Re:Live Testing is Where F-Script Really Shines (1)

Bastian (66383) | more than 8 years ago | (#15610261)

That's how I tend to do all of my testing, too. When I started combining an F-Script console with the "Fix" button, debugging became almost fun. I can just keep poking and prodding at a bug until I pin it down without having to worry nearly so much about continually dragging the program back to the conditions where the bug came out or any of that, because I can bang out an F-Script block that does that on the fly for me, and then tweak it as needed without ever having to restart the program.

misleading (1)

m874t232 (973431) | more than 8 years ago | (#15611758)

The article seems to be more about exploring class libraries, not "the object system" (which would mean low-level analysis of how methods are invoked etc.).

Furthermore, there is little that is OS X specific about either the class libraries or the object system: the object system comes from Smalltalk, via Stepstone, and the class libraries come from NeXT and borrow heavily from Smalltalk and also exist in GNUStep (and, yes, people are working on porting FScript to GNUStep).

Impressive (0)

Anonymous Coward | more than 8 years ago | (#15612680)

I was not aware it was possible to do things like that with Objective-C. It's neat.

Other scripting environments (0)

Anonymous Coward | more than 8 years ago | (#15615195)

There are several other scripting environments [fscript.org] for Cocoa, including bridges for Ruby, Python, Perl and Lua. AFAIK they don't have graphical tools like those provided by F-Script for playing with Cocoa objects.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>