Slashdot Mirror

But I'll grant you any day that Obj-C could do with some modernisation, in particular w/r to namespaces.

In the end namespaces are very little more than appending more characters on a name. You can get most of what namespaces do just by adding a unique string to part of your class name. Yes, there is a possibility for clashes if someone chooses a string which is the same as yours but how often do people use outside classes other than the ones in the Cocoa frameworks?

At best there should be some sort of prefix directory where developers can register their class prefixes and make sure that they have a unique string. Apple already uses NS and CF so most developers know do avoid using them.

Here's some good reading on the topic:
Cocoa Style for Objective-C: Part I
ChooseYourOwnPrefix

http://cocoadevcentral.com/

Agreed. I just started using CoreData, and it's a pretty amazing technology. For instance, take a look at this tutorial. It's a whole working database-based app without writing a single line of code! If you want custom behavior, enhancing is very easy, too.

Key-Value Observing has revolutionized Cocoa development, most developers just didn't notice (b/c it takes some time to get used to it).

...noting that Microsoft does not have the access to the Macintosh operating system that it would need to compete

Secondly you are making a mistake thinking that all code is easy to read when it is good. This is a lie.

So you're suggesting that code can be good but hard to read? That seems contradictory. You must have lower standards for code than me.

But when you get into any specific details of that code or if the code is not a simply a goto database/do some formatting/print/get input from user/do some validation/write to database code, but something like: switch the coordinate system, do some trigonometry, create a complex data structure, display 3D world, then there is no way that code can be fully self documenting.

Can you give a specific example of some code that can not be self-documenting? I've done coordinate systems, trigonometry, data structures, 3d graphics, etc., that were all pretty self-documented.

For good examples of how to name things, see Cocoa Style for Objective-C.

Sure, if you just use variable names like "r" and "t", then your trig code will look like ass. But if you call them "angle-from-horizontal" and "angle-after-rotation", it's clear as day to me.

It's completely multi-platform, and is used on multiple platforms. Rewriting it in Objective-C isn't feasible from either a time standpoint, or from a platform availability standpoint (even if I did have years to rewrite and retest all this code in Objective-C, it would then only compile and run on OS X, and perhaps Linux if I was very careful). So it's not going to happen.

Ok, then write the controller part of the app using Objective C, and keep the model in Java. Problem solved. If you need some help on that, take a look at my article.

Because of the internal representation (0x1039), I don't think the last digit can be higher than nine. I'm sure a Mac programmer can correct me.

http://cocoadevcentral.com/articles/000067.php

http://blogs.msdn.com/oldnewthing/archive/2004/02/ 13/72476.aspx#72670

This is actually a great time to discuss this with Xcode 2 on the horizon. Xcode 2 is the newest version of Apple's free IDE that comes with their developer tools and can also be downloaded from Apple Developer Connection [Free Registration Required].

Along with GCC4.0 and new UML-graphing utilities, this next revision that'll be available on the 29th looks like it's really packing some enhacements.

I've been using Xcode 1.5 (the current iteration) to work with Cocoa Objective-C (see above for tons of info on the language) and coming from a platform neutral C++ and PHP background have found it very intuitive, and if coded correctly Objective-C is a pleasure to use. I can say that Aaron Hillegass' book Cocoa Programming For Mac OS X is a great utility, along with CocoaDev and Cocoa Dev Central.

Good luck!

Nah, you can do it with a regular Cocoa app.

CGDisplayCapture grabs a screen, and puts a "shielding window" on it, in front of everything else.

You can get the windowLevel of that shielding window. Once you have that, you can create a regular window that is above the shielding window (ie, with a higher windowLevel) and thus visible. Or, you can take an existing window, and set its window level.

There's a simple Cocoa example, at CocoaDevCentral.

What you mean like a .app Package for Mac OS X? Granted, things get a bit more bloated by pseudo-statically linking frameworks, but it has the effect of making installation and removal dead drop simple.

You can implement rather complex GUIs without writing a single line of code yourself (more so now thanks to the contoller objects supported

Recently wrote an article on this, for those that are interested:
Introduction to Bindings

- Scott

DBM has really hit a new low with this "article". It is almost painful to read through with the gaping holes in logic and diction that would make a SMS junkie teenager blush.

According to DBM's logic Apple might have a real nice developer platform on their hands if they'd only port the base API to other platforms. I find this assertion to be pretty ridiculous. OpenStep already lost this battle a decade ago. The problem NeXT ran into with OpenStep was developers were already entrenched with native and proprietary APIs on their platforms of choice. Few developers were willing to drop all of their current code in order to develop OpenStep applications.

There's also the small problem of Apple's OpenStep derived frameworks (AppKit & Foundation Kit) being a tiny (though important) fraction of the frameworks available in OSX. If only Cocoa were ported to other platforms developers would have to write their own frameworks for advanced functionality. Instead of being able to leverage Apple's DiscRecording framework a developer would have to write, maintain, and package their own in order for their app to be as cross platform as Cocoa. Then the argument would be Apple ought to port their more advanced frameworks in order to draw in more developers.

If Cocoa were to be ported to Windows and Linux tomorrow it wouldn't magically bring oodles of developer talent to the Mac. Think of how many KDE and GNOME apps run on Linux, FreeBSD, Darwin/PPC, and Windows with no platform specific patches despite their common API usage. Only the simplest of Cocoa apps would run with only a recompile (or fat compile) on multiple platforms.

DBM doesn't pay nearly enough attention to Java in his little rant as he should. With Java Apple's already got a nice cross platform development environment to work with. Apple ships two J2EE environments, WebObjects and JBoss, as well as J2SE on their client systems. MacOS X is also bundled with a Java/Obj-C bridge which DBM almost totally ignores. The Java bridge gives OSX a serious advantage as a development and deployment platform for Java applications. With the Java bridge a developer can write a single cross platform application model and then stick a native Objective-C/Cocoa based GUI on top of it. Java's huge cross platform development base with a native Aqua GUI.

There's a few languages such as Python, Perl, and Ruby that can be bridged to Objective-C and can access Cocoa. That is not to mention C++ code can easily access Objective-C classes and thus Cocoa just as well as anything else. I don't really see Objective-C to be much of a hurdle in the development of Mac applications.

What it really comes down to is developers who don't want to abandon the APIs they are used to. All porting Cocoa would do is let Linux and Windows users run Mac applications. If everyone could run Mac applications on non-Mac computers the Mac would become a commodity item and Apple would be little more than an iPod manufacturer that happened to write some software. If Macs ran Windows there'd be no difference between a Mac and an HP. If PCs ran MacOS they'd be no different from Macs. In either case Apple would no longer have a whole product to sell. Without a whole product to sell Apple would either just be yet another software company or yet another hardware company. There's hundreds of each of those. Apple makes money by selling a whole computer product.

and in the case of Eric, direct fascists: Eric moderates the Cocoa-dev mailing list, and anyone he doesn't like gets the boot. [...] The worst of it is that all of this is taking place with the implicit nod of Cupertino: for example, Cocoa-dev is run by Apple themselves.

I think you've got your lists mixed up. Erik doesn't moderate cocoa-dev. He did moderate cocoa-pro, but that list was decomissioned when I took over Cocoa Dev Central from him. He's been a friend of me for a while, so he can't be too bad. :)

I trade emails with Scott Anguish occasionally and have met Aaron once. Neither strike me as rude. Aaron was extremely friendly, in fact. Scott A. has always gone out of his way to help people on the lists I've been on.

- Scott

The first time I saw Tcl was in the Alpha editor under MacOS 7, so it was available there. Wether or not Tcl would have been a good choice for a system-wide scripting language is another arguement.

Note that there are now AppleScript libraries for Python, and Perl has Mac::AppleScript and Mac::Glue modules, among others, so it's fairly easy to trigger AppleScript events from something other than applescript. In fact with the PerlObjCBridge it's possible to make Perl the data model for an objective-C gui.

O'Reilly's MacDev center

CocoaDev.com

Both have entry-level ProjectBuilder tutorials, including the famous one-line web browser (CocoaDev) and text editor (O'Reilly) tutorials.

Apple integrates the many apps together with publically accessible APIs, so that other people may do the same.

Careful how you bash Microsoft. It's fun, and I'm using Jaguar this minute to post, but nobody does a better job exposing APIs to the public than Microsoft and COM.

Guess how long it takes to make a web browser in Visual Basic 6? Seconds if you know what control to use (Microsoft Internet Control) -- and seconds if you don't; there's a pre-built form you can add from the Project-Add Form menu item. How long to add Media Player? Seconds. How about automate Excel or Word? Those are a little more complicated, but only b/c of their more complicated APIs.

(And yes, I know about cocoa and embedding browsers)

Don't get me wrong. I don't like Microsoft's silly claims that they can't take IE out of Windows OS. I hate the way they embrace and extend. I hate the way they aggresively go after smaller businesses and spend them out of existence. (imo, etc)

But when it comes to making something quickly that communicates between two application engines, whether first or third party, you won't get any more robust a solution than VB6. MS loves opening up their APIs. Means every one of your users will also have to pay the Windows Tax.

When they decided to use KHTML for Safari, I thought they would at least release the source code for Safari and not just the changes to KHTML..

Would it have killed you to spend 0.12 seconds on google before opening your mouth?

http://developer.apple.com/darwin/projects/webco re /

That's every part of safari that matters, right there, for your FSF-approved open source development pleasure. No, the shiny front-end isn't included, but that's not going to bother too many coders considering that you can write your own frontend in as little as one line of code, or if you're feeling particularly clever, zero lines of code. (Note: while the examples given are in ProjectBuilder on MacOS X, there's no intrinsic reason why you couldn't do the same trick with GnuSTEP on Linux, and a GTK+ wrapper would only be slightly more work.)

And WebCore isn't the only "unique" OSX software that they've released the source to. Need a streaming media server? A fully functional ZeroConf implementation? A crypto-key management framework? All there for the taking.

No, Apple isn't going to release the source for iPhoto or Final Cut so you can play with them for free. Cry me a freakin' river. Then get a job.

And while I'm here: the casual, contracted form of "would have" is "would've", not "would of". Please spread the word.

Safari uses webcore, and has tremendous difficulty (even yet) with e-commerce and online banking sites.

Sure, check this article for instructions on how to make a one-line-of-code web browser in Cocoa using WebCore (and the comment at the bottom of the article which tells how to make a no-line-of-code browser!)

He's right on target about developer training & documentation. It sucks big-time: poorly categorized and there is lots of missing information.

When I'm looking for an answer to a technical problem, I typically find answers at sites like Mamasam or CocoaDev. The Cocoa Dev Central site is a good source of sample code, too. Many more resources are listed here

Historically, Mac developer's have been very picky about this: Inside Macintosh is wonderful. It's an excellent technical reference presented in a consistent and easily readible format.

If you are porting your java-based massive application to Mac, than ObjC is probably out.

That's not necessarily the case. Cocoa can (mostly) transparently manipulate Java objects from Objective C. See here for more info.

Also, O'Reilly's Building Cocoa Applications is excellent for the beginner, although I wish they would publish AppKit & Foundation in a Nutshell for a good off-line reference.

Some other good references:

• http://www.stepwise.com/
• http://macdevcenter.com/
• http://www.cocoadevcentral.com/

There's a decent article on CocoaDevCentral about setting up CVS and ProjectBuilder.

I managed to get it working without too much trouble. It works pretty much the way you'd expect an IDE to work with SCM.

There's a decent article on CocoaDevCentral about setting up CVS and ProjectBuilder.

I managed to get it working without too much trouble. It works pretty much the way you'd expect an IDE to work with SCM.

I have just started to develop on the OS X platform using the Apple developer tools and online tutorials, as well as Aaron Hillegass's brilliant Cocoa Programming for OS X book (the link is to Amazon, there was also a review of it here on Slashdot). Some resources I have found indispensible have been:

www.cocoadevcentral.com
& of course,
developer.apple.com

It is a nice environment to program in, although I am finding the objective C and the size of the framework to be the main hurdles. Still, there are so many great resources online and packaged with the developer tools from Apple (a free download with tons of documentation and examples), that I am slowly learning.

Hewligan
My Blog: BrainMess

Hi,
iDevGames.com has an interview with the author, Aaron Hillegass of the Big Nerd Ranch here:
Interview
You can read about why the Apple/O'Reily book was "thrown" together.

My site has Cocoa code and will be adding some Cocoa game code soon. I also recommend http://www.cocoadevcentral.com/ for more Cocoa info.

Cheers,
Carlos Camacho
Editor
iDevGames.com