Friday, April 19, 2002

Some might read that last post and conclude that I think Carbon sucks. It doesn't and I don't think that. Almost all of the my desktop app development is built upon the Cocoa APIs because I have yet to find anything better (and I have been actively looking for 10+ years). However, more and more of my applications have chunks of functionality implemented with the Carbon or CoreFoundation APIs. Typically, this is because there are features of those APIs that simply aren't available in Cocoa. This isn't so much because Cocoa is incomplete. It is an issue of granularity. In Cocoa, the application frameworks do most of the mundane task of creating a standard, well behaved, X application for you. You simply modify that standard behavior slightly and subtly to express the features unique to your application. In Carbon and Core, the developer must expend a lot of effort in setting everything up such that the app looks and feels like a well behave X application. It is a lot of work to do and it is one of the key reasons why a lot of Carbon applications do not feel 'complete' or have minor behavioral differences when compared to other applications. (Example: The Finder -- it has improved vastly over time, but still has certain quirks that make it feel 'different'). However, Carbon and Core have the distinct advantage of allowing the developer to dive into the guts of the OS and do all kinds of cool things at a low level that would be difficult or impossible to do from a high level API like Cocoa. Example: Drag and drop. In Cocoa, drag and drop is trivial to implement; requires only a few lines of code to be a dragging source or destination. On the other hand, Carbon/Core drag and drop requires a lot of tedious code. However, Carbon/Core allow for a number of possibilities that can't be done from Cocoa (specific example: drag and drop something on the Finder and have the app figure out the exact path of the drop -- can't be done in Cocoa, can from Carbon with some fairly gnarly code). Over time, we will likely see Cocoa object wrappers around a lot of this functionality. 3:14:43 PM

Paul Boutin writes: I see this slow surfing every time I fire up the aging Windows laptop with just 64 megs of RAM that I need to use now and then to do some work with my Lycos job. This old machine can load pages faster than my newer PowerBook running OS X 10.1.4 on 192 megs of RAM (Yeah, I know my RAM is still too low to get the most out of OS X...). But with OS X's true multitasking capabilities and my work style - I flip between applications and tasks frequently - the slower browsing speed is not a deal breaker. Gee, that's funny, on all of the machines I use-- from G3 iMacs through to my powerbook G4, I don't suffer from this problem. I use LaunchBar to switch between apps and, as such, my hands area already on the keyboard and ready to go and the delay between app switching takes about the same time it takes for my brain to focus on the various windows that just popped forward. First-- get more memory. Memory is cheap, even with the recent price increased. 512MB is my minimum. Not because OS X, in itself, is a memory hog (though the graphics layer certainly is), but because the operating system will take advantage of every last byte of available memory to buffer access to the disk. Virtual memory is great, but only hitting the disk once to bring in a hunk of data is far, far superior. On a powerbook, this is especially crucial as portable hard drives are slow, Slow, SLOW! Any virtual memory activity on a powerbook is guaranteed to be noticeable simply because the drives are slow. (I would suspect sticking a bunch of memory in your 'book will also increase battery life by decreasing page swaps... but I haven't remotely qualified this at all.) I also try to avoid slow applications. I find that a lot of the carbonized applications out there are not very well engineered. The same can be said for Cocoa apps, but the very nature of Cocoa means that the core still plays well with the rest of the operating system. Instead of IE, use OmniWeb 4.1b4. It is faster than IE by leaps and bounds. It doesn't pause very often, either-- something that drives me batty with IE. Chimera-- though very alpha-- is blazingly fast, as well. Obviously, it isn't OS X that makes browsing slow. It is a combination of bad engineering or good engineering for a completely different system [OS 9] that has been ported, but not fully optimized, for OS X. iCab, Opera, and Mozilla all suffer from this-- they are all nice browsers and each has their attractive strenghts, but they all feel like they have not been optimized properly. I have also found that some applications-- all Carbon so far-- have a nasty habit of consuming a bunch of CPU when doing basically nothing. Microsoft Word will "idle" at 50% CPU utilization unless you turn off live word count, for example. Certainly, there is a great need for optimization throughout OS X. Given the history of the operating system from the NeXT day, it very much appears that history is repeating itself. Every release of the NeXT operating system very much followed the 'Make It Work, Make It Right, Make It Fast' philosophy of software development. It seems that some of the third party developers are stopping the Carbon parts in between Right and Fast. It works Right, but it isn't Fast because the code still assumes an OS 9 - like operating environment. 2:45:10 PM

Kjell Nilsson recently mentioned how difficult it is to find desktop images that are both pleasant to look at and don't hinder the ability to deal with icons/information on the desktop. Very true. After I picked up a digital camera a couple of years ago (Sony DSC-F505), I have found that some of the best desktop images can be had by taking pictures of textures found in the world around us. An example to the right. Clicking through downloads a 1600x1200 pixel image. This isn't one of my favorites, I'll try to upload some more if anyone cares. 11:13:11 AM