« December 2004 | Main | July 2005 »

June 22, 2005

Too Many Services

Today I came across ACP Web Services on VersionTracker. It promises to “enhance Services menu with 263 additions”. You've got to check out the description. Yow! Where do you even begin?

I make no judgement on the product: there's probably some really cool services in there. But another 263? How am I going to find them or even remember that they're there?

I already have more services than I know what to do with, installed automatically by apps that never even told me they included services. My Services menu is effectively unusable since it's impossible to quickly pick something out. I never even look at it anymore. And now I can add another 263! No thanks.

The thing is, I used to adore Services. I think they're a really clever hack on the pasteboard and allow for (potentially) tremendous integration among apps, just by passing around transformations of common data types.

But menus like these, I just don't want to see.

NeXTstep had a way, in Preferences, to hide or show any of the items in the Services menu. This was really nice. Basically you just could remove the services you never used, or add new ones in a few at a time. It allowed you to cut Services down to a super-streamlined set, tailored exactly to how you use them. Max OS X needs this, too. I'm completely surprised this still isn't in there.

I miss having a sane Services menu. If someone can figure this out, it's a hack I'll gladly pay money for…

Posted by ttalbot at 8:28 PM | Comments (9)

June 18, 2005

Core Data Rocks More Harder Every Day

The more I use Core Data, the happier I am with it. I think it's an amazingly clean persistence framework for desktop applications. I think when us old-timers stop seeing it as “EOF-lite” and start thinking of it as an absolutely fundamental part of Cocoa, some astonishingly powerful apps are going to come from it.

A tip from WWDC: option-command-clicking on a model's graph paper will put up a temporary, scaled, bezel-style view of the entire model. Useful for seeing connections that have scrolled off-screen.

Posted by ttalbot at 1:35 PM | Comments (3)

June 15, 2005

Karelia Software previews Sandvox

Of all the Mac news sites to cover our little announcement at WWDC, I think Dave Caolo's post to The Unofficial Apple Weblog is my fav. Just wanted to hang on to the link here while I process my notes.

Posted by ttalbot at 4:04 PM

Surviving (and enjoying) Xcode 2.1

As Dan decried on his blog Monday night, our transition from Xcode 2.0 to Xcode 2.1 wasn't the smoothest it could have been. I just wanted to mention that, with a little help from Jonathan Wight, I did get things building that night and I'm really looking forward to the other improvements and new features in 2.1. For the record, we won't be going back to 2.0. Intel will happen.

So what was all the fuss? It turned out to be, I believe, a complex interaction of target-based build settings that were inconsistent across our frameworks. To make sure that Sandvox is incredibly extensible, I keep pushing more and more code into a public framework that we'll expose to third party developers. There are roughly 35 targets in this framework: the main framework itself, and various categories of plugins. Wrangling all of these into a common build system under 2.1 proved to be quite a chore.

The upgrade process from 2.0 to 2.1 creates a new .xcodeproj project file and, apparently, copies the old project settings to every target. Some interaction among the various target settings and the project configuration settings caused the framework to be effectively undebuggable with gdb. Exactly why, I'm still not completely sure.

Following Jon's advice, I basically removed any and all customized settings at the project configuration level. I then set up several Xcode configuration files, new in 2.1, that hold purely text-based representations of the various settings. I set up essentially six configuration files, one for Application, one for Framework, one for Bundle, with both Debug and Release variants. I then set each target to base its configuration on a particular file, depending on project type and configuration.

This turned out to actually be a very clean approach: each target now builds from a very transparent configuration file, often varying only in Product Name, Wrapper Extension, and location of its Info.plist. Getting to that state, though, was no small amount of work!

I'm still not sure Apple's cracked the nut on this one: it's really nice to base everything off a few common text files, but it also feels like a step backwards. I've effectively abandoned the GUI. I'm back to worrying about things like GCC_GENERATE_DEBUGGING_SYMBOLS rather than just flipping a switch. Is this progress?

Still, though, dependency analysis seems much better with Xcode 2.1: that, plus the addition of conditional breakpoints, breakpoint actions, and watchpoints certainly make the upgrade worthwhile. Don't let it scare you...

Posted by ttalbot at 3:06 PM

Out of hiding and into the fire

At last year's WWDC, I (purposely) kept a really low profile. I was already working on a new app for OS X, stemming from an idea that Dan Wood approached me about a few years ago. Dan, of course, was across the street at JavaOne demo'ing Project Alameda, Sun's Java-based successor to Watson. Not wanting to really give any details about what I was working on, and sort of waiting to see what would happen with Dan and Watson, I kept pretty much mum.

That's not to say I wasn't listening. Core Image, Core Data, WebKit editing. Yep. I ate it up. Very tasty stuff. But, still, I wasn't ready to say anything.

This year, things went a little differently...

As it turned out, Sun dropped the ball with Alameda, Dan rejoined the team last Fall, and we've been coding away getting ready to ship this new app as soon as we can. Not wanting to go through another conference with my lips sealed, I pushed pretty hard that we announce by WWDC 2005. And I'm sure glad we did. Dan and I spent a good part of last week just huddled in the labs with Apple engineers and our code, hitting every major area we had questions about: Xcode, Core Data, Core Image, Quartz Composer, Automator, and, of course, WebKit. (Don't worry, Barry, I'll be bugging you about Sync Services in short order.) I really want to thank everyone I met last week for their help and suggestions. We walked away from WWDC 2005 with a ton of ideas to make this app even cooler.

So what's the app?! Of course, it's Sandvox. We unveiled it at Buzz's Weblogger Dinner at Thirsty Bear on Monday night. (Thanks Buzz!) I made Dan give demos until his voice went hoarse. (Thanks Dan!) I was nervous to see what the reaction would be. We couldn't be happier with the response. The people who saw it got it right away, even in the rough, alpha state it was in. Since that night we've gotten a tremendous amount of interest through the sign up on our site and a lot of great feedback that will surely shape the product between now and release.

So that's it. No more keeping silent. I'll be blogging here regularly, as well as on the Sandvox Weblog, about our progress, the present and future of OS X, Cocoa, Xcode, how design affects our lives, and the craziness of living in LA.

Stay tuned!

Posted by ttalbot at 2:38 PM | Comments (2)

June 14, 2005

NSBindingDebugLogLevel

One of the small lab victories to come out of WWDC was getting NSBindingDebugLogLevel working with our projects. As marvelous as Cocoa Bindings are, if you've got a mistyped key in a nib file, it can be a real pain to track down. NSBindingDebugLogLevel was supposed to be the answer, but neither Dan nor I could get it to work.

It turns out that we each had a .gdbinit file in our home directories that specified fb -[NSException raise]. Normally this is a good thing since we like to break on exceptions without having to set the breakpoint every time we reset our individual pbxuser files. However, and here's the answer, breaking on raise stops gdb before the bindings log gets a chance to print. Since we had the breakpoint in a set-and-forget external file, the bindings log never appeared.

So, good bye .gdbinit. Hopefully Xcode 2.1 won't require trashing my pbxuser file quite so often.

Thanks to the Core Data team for helping me track this down.

Update: I should add my preferred way of setting the option. In Xcode, add the argument -NSBindingDebugLogLevel 1 to the target's executable and flip on the switch.

Posted by ttalbot at 11:36 AM | Comments (3)