You’re in luck, because you can open a website URL from just about anywhere on a Mac by using Spotlight. This is arguably the fastest way to get to a website by URL, aside from launching a website bookmark from the Mac Dock anyway. Be anywhere free download - WireTap Anywhere, Send Anywhere, F-Script Anywhere, and many more programs.
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? 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. 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.
F-script Anywhere For Mac Free
It can't be coded. Or at least, it is strongly discouraged.
This graphical nature took me quite awhile to get used to. 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 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? 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 too.
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. 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 b. '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 my. 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 N. 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 languag.
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.
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. 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!