Posts Tagged ‘Mac OS X’

Keeping optimal autorelease pools

Saturday, April 4th, 2009

Martin Pilkington on autorelease pools:

However, a problem arises when you’re creating a lot of objects at once. The obvious solution is to initialise and release objects by hand in this case, but sometimes it isn’t possible. A lot of objects returned by Cocoa methods are autoreleased (by convention any object returned by a class method (other than +new or +alloc) should be autoreleased).

This is a good practical example of autorelease pool manipulation, including numbers showing before and after.

iPhoto Faces fail

Friday, March 27th, 2009

iphoto-fail

iCal View menu

Monday, December 22nd, 2008

Here’s iCal’s View menu.

ical-view-menu

What’s so confusing about it? You really need to see how it interacts with the iCal main window to understand. We’re going to be focusing on the group starting with “Hide Calendar List.”

The iCal main window looks like this:

ical-main-window

The sidebar on the left side of the screen looks simple enough. Now let’s look again at the menu. What would you expect Hide Calendar List to do?

Wrong. It does this:

hidden-calendar-list

 

Both the calendar and mini month calendar are hidden. Hiding both makes sense, but calling the command Hide Calendar List doesn’t. Go back to the menu, and we see the helpful command “Hide Mini Months.” What Mini Months? Oh, the ones that were on the iCal window, but aren’t anymore? I wonder what it does?

It does this:

hide-mini-calendar

That’s right. Choosing Hide Mini Months showed the mini calendar.

So here’s how the menu commands work:

The first command, Show/Hide Calendar List, hides the entire left side bar: The calendar list and whatever is under it.

The second and third commands, Show/Hide Mini Months/Notifications, control what’s under the calendar list, but still controlled with the Show/Hide Calendar List command. And they don’t actually do what they say they’re going to do if the calendar lis is hidden. They’re mutually exclusive: Think of them as Under Calendar List: None, Mini Months, or Notifications.

The fourth and fifth items are entirely independent of the first three items.

Granted, coming up with menu commands to control a UI like this is hard. But that’s no excuse to throw your hands in the air and settle on this UI.

Save changes?

Friday, December 12th, 2008

Is it any wonder I sometimes miss saving?TextEdit

Mail

Inkscape on Windows

Inkscape on MacNotepad
EditPad Pro

Menu zen

Thursday, December 11th, 2008

With a 1280×800 screen, I decided to put a little effort into reducing my menu bar baggage.

Menu Zen

What I removed:

  • BlueTooth: Useful, but not on a day-to-day basis.
  • Time Machine: This system isn’t backed up. What? No, really. Everything important on it is either in MobileMe or Subversion. All my other systems use Time Machine.
  • MobileMe Sync: Knowing when MobileMe is syncing isn’t really that useful.
  • Keychain: Because I mostly use this to access Keychain Access, and I can just use Quicksilver.
  • Fast User Switching: Because it’s usually just me using this computer.
  • Quicksilver: Because it functions just as well without the menu.
  • Volume: Because there’s keys on the keyboard.

What I’m keeping:

  • smcFanControl: Because I want to run smcFanControl, but there’s no way to turn off the menu.
  • ExpanDrive: Again, no way to turn off the option.
  • iChat: Because I want to be able to quit iChat and stay online, and keeping it in the menu is requirement. But I never use the menu.
  • WiFi: Because wireless connections take just long enough to establish for this indicator to be useful.
  • Battery: Obvious.
  • Spotlight: Because there’s no official way to remove it. If there were, I’d probably use Quicksilver to activate it, but as it is I use it a lot too.

What I may change:

  • Add Script menu. Because it’s cool.
  • Display temperature in smcFanControl. Very anti-zen, but useful information. I’d prefer if the temperature was in the menu somewhere after you clicked it, like Apple’s battery menu and the “battery remaining” time.

Mac OS X interface flaws

Friday, November 28th, 2008

Here are a few things I’ve noticed that just don’t make sense in Mac OS X v10.5.

  1. Desktop & Screen Saver rolled into a single preference pane. Why? Are we that convinced that one day we’re going to have a screen saver running in the background as our desktop, and the only way to configure it is to have it in the same preference panel?
  2. Keyboard & Mouse are a single preference panel (but Trackpad is separate). Again, why? The only conceivable answer is that Apple thought it important that the battery levels for both the keyboard and mouse are in a single preference pane, which also has an option to add a new device. But the “add device” functionality is already duplicated in Bluetooth.
  3. Exposé & Spaces are a single preference panel. Are they related? Well, a little, but not that much. And how does Dashboard fit in here, which is also thrown in for fun?
  4. Translucent Menu Bar is in Desktop, rather than Appearance.
  5. Scroll bar behavior is in Appearance.
  6. The number of recent items to show in menus is in Appearance.
  7. The option to automatically adjust keyboard back lighting is under Displays. (But typing “Dim” into the preference pane search only hilights the Energy Saver panel.)
Oh, sure, it’s better than Windows. Of that there’s no doubt. And sure, we got here via a series of small, well-intentioned steps. But let’s not get too smug about Mac OS X: It still needs a lot of tuning to be intuitive.

I need to start using Windows more

Thursday, October 23rd, 2008

The reason? Simple. I’m using other operating systems so little that I’m only able to complain about Mac OS X. I’m starting to look like a Mac hater.

But lest anyone be confused, I’ll be specific: Mac OS X is not perfect. It is, however, less not-perfect than Windows. And until an even less not-perfect OS comes out, Mac OS X is my OS of choice.

Two strikes…

Saturday, October 18th, 2008

Apple’s sample code includes an annoying disclaimer at the top of each file. I can understand the need for a disclaimer, but this code takes it to an obnoxious level: every .h file or .m file you open, you can’t see any actual code to to the length of the disclaimer.

Strike one is including that disclaimer in every file. If the lawyers can’t accept “Please see DISCLAIMER.TXT.” in place of 38 lines of bullshit, you have stupid lawyers. Fine, though. I’ll just remove it, right?

Luckily, Xcode has a great Find-Replace tool. So we’ll use it.

And here’s where we hit strike two:

It’d be nice if we could blame this on Xcode. Indeed, it’s Xcode’s fault that the text is so long. But it’s Mac OS X’s fault that the sheet goes under the dock rather than truncating before it.

Delete drive

Sunday, September 28th, 2008

Thoroughly disguisted by the clutter on my desktop, I decided to delete all of it. I selected everything, deselected a few things I wanted to keep, and hit command-delete (the keyboard shortcut for Move to Trash).

Yes, WxFPP_EN is indeed my Windows XP CD, left over from a failed/aborted attempt at installing Boot Camp. And Mac OS X really is asking me if I want to delete it immediately. Clicking Delete caused this error to appear:

Error -61 looks familiar, so I looked it up: wrPermErr. Yes, that’s right: the Leopard Finder is actually trying to delete files off the CD.

Okay. Bad enough. But at least it didn’t crash, right? I click OK:

After all of that my desktop is still a cluttered mess.

Apple, if Finder stability is one of your goals ur doing it wrong. Hitting command-delete on a volume shouldn’t actually try to delete the files form it. This is laughably bad.

WarpedVisions on Objective-C, square 1

Sunday, August 24th, 2008

Bruce over on WarpedVisions writes on entering the world of Objective-C and Cocoa development.

I’m barely past square one, but I found this an interesting title. Of course, what Bruce means is the whole Mac OS X development experience, but it’s interesting that he worded it in the title as learning Objective-C. It’s a simple, concise yet technically inaccurate way to label the knowledge.1

Objective-C just might be the easiest part of Mac OS X development. The hard part is simply knowing what objects are available in Cocoa, where they are, and how to string them together. Basically, the typical framework problem. Don’t get me wrong, I’m still at the very bottom of the learning curve here!

Objective-C itself is very nice; it’s a truly minimal extension to C. I’m amazed at how it’s still a very complete object-oriented language yet so simple and small, with everything done the simple way.

When I first started with Cocoa, I was thinking of compiling notes together so I could write a short book/essay on “Learning Cocoa for C++ developers,” but as I’ve gone I’ve realized the first chapter should be “Forget everything you know about C++. You think need ___ to do ___? You do in C++, but in Objective-C just use the Cocoa class ___.”

  1. And I’m not intentionally picking on Bruce here. I have said it this way, and probably will again, and he does get it right in the text, as he noted below. []