Menu

Tag Archives: cocoa

Brent Simmons reacts to the news that the upcoming Photos app for Mac uses a private UXKit framework. Instead of being the full UIKit-based replacement for AppKit that many developers want, Brent suggests it could be a minimal framework just to make some things easier:

“I could imagine a minimal UXKit that isn’t meant to replace AppKit but that can be used with both AppKit and UIKit. It might have UXColor, which would wrap UIColor and NSColor. Same with UXFont and UXImage. UXTableView could present a simplified superset of UITableView and NSTableView/NSOutlineView.”

Like Brent and many other developers, I started this same kind of compatibility work when porting Tweet Library to the Mac. I ended up abandoning the project because it’s a slippery slope to basically reinventing Chameleon. (Also, back in 2006 I ported parts of Microsoft’s MFC C++ framework to Cocoa and it was a lot of work. I’m not eager to repeat that process.)

I agree with Brent that we don’t necessarily need a completely new AppKit. I’d love to see Apple standardize the foundational classes which are nearly identical already — colors, images, and fonts, as Brent mentioned — as well as UI elements that could be the same without a real cost — views, buttons, labels, table cells, and maybe split views. These UX-prefixed classes wouldn’t do everything their UI and NS versions could do, but they’d allow developers to move more code into cross-platform layers of their app by sticking to the common properties and methods.

As tempting as it would be to throw in iOS-only classes like UINavigationController, I think that would be outside the scope of a minimal UXKit. Candidates should already exist in similar forms on both platforms.

WWDC 2015 is going to be fun if Apple attempts to tackle even a little bit of this. A minimal UXKit would strike a good compromise between the usual iterative improvements to AppKit and a more revolutionary change to the frameworks.

Today is a good day to release software. “MarsEdit gets a nice update”:http://www.red-sweater.com/blog/346/marsedit-12-growl-picasa-and-vox and “NetNewsWire 3.0”:http://ranchero.com/?comments=1&postid=1646 ships. At VitalSource we also just released “Bookshelf 4.6”:http://www.vitalsource.com/index/bookshelf today, which lays the foundation for media-rich textbooks and adds a highlighter rating UI for any subscribed highlighters you have. This data will bubble up in a few places in the future to allow you to discover people and books, although for now it’s one-way.

Here’s a “short screencast of the rating interface”:http://www.manton.org/screencasts/2007/bookshelf_rating.mov (12 seconds, 700k). The star widget is a simple Cocoa control that hits a web service in the background. It was fun to write and surprisingly not very much code.

Wii Transfer 2.2 is taking longer to get ready than I had planned, so I’ve decided to post a public beta while the last pieces are polished up. You can “grab it from the news section”:http://www.riverfold.com/software/wiitransfer/ of the Riverfold site (lower right). It is very close to being done, but giant chunks of code have been completely rewritten. I hope the extra testing will help make 2.2 an extremely solid release, and get some of the new features in the hands of users as soon as possible.

So what’s new in 2.2? iTunes playlists and several new preferences to control picture sharing top the list, but there are at least a dozen changes underneath the hood.

The web server built into Wii Transfer has seen some work in particular. Music browsing now uses the iTunes Music Library.xml file for everything rather than look at directory contents, and you can change the port number on the fly without restarting Wii Transfer if there is a conflict with any other applications.

I’ve also added reflections to the album cover art! You can see a “screenshot here”:http://www.manton.org/images/2007/wii_transfer_cover.jpg and another one of “the collage for playlists here”:http://www.manton.org/images/2007/wii_transfer_collage.jpg (these are from Safari, but it looks mostly the same on the Wii). This was really fun to do, but unfortunately it somehow introduced a subtle double-release bug that I spent hours fixing. It would only happen if the album art could not be found in iTunes and while multiple connections were hitting the server (i.e. it was ultimately a threading issue), and maybe only every dozen requests.

I tracked it down by using ab (Apache Bench), pointed at Wii Transfer. I had a shell script with a bunch of lines that looked like:

ab -n 200 -c 4 "http://localhost:9000/m/Beatles.cover

This URL asks Wii Transfer to grab any album art from iTunes for The Beatles, apply the reflection and return the JPEG data. It is flexible because you can send it any search strings. Other examples might be: Evanescence%20Door.cover or Zoo%20Station.cover. I was a little surprised that my little server was actually pumping out pages fairly quickly considering all the AppleScript and Quartz stuff going on. 10-20 requests per second isn’t much for a real web application, but for an app that is by definition single-user, it’s perfect.

The reflection code was made even easier by “BHReflectedImage”:http://bithaus.com/2006/11/05/nsimage-reflection/, which I modified to work with black backgrounds and then wrapped up in other helper methods to composite the cover and reflection together. When I first ran across this code I didn’t even notice it was written by Jeff Ganyard, who I’ve known for years and still run into at WWDC. Thanks Jeff! This goes in the about box credits with a bunch of other mentions. There is a really active Mac developer community that contributes source pretty freely, and I hope to add a few things to that collection one of these day as well.

Last week I said I wasn’t interested in an iPod phone, unless it was something no one had even thought to expect. Well, it is. I am blown away by the iPhone. The thing runs Mac OS X.

The iPhone is really inspirational in terms of UI design polish. You can tell they put some years into it. I was playing with Tiger’s NSAnimation the other night (sort of a poor man’s Core Animation), and it reinforced for me the fact that UI effects are no longer optional pieces of software design. They can both visually supplement the user interaction and just make the application experience more enjoyable. Disco, for all the criticism as a glorified Disk Recording framework wrapper, is fun to use. Same goes for the just-released Snapshot 2.0, which has a really thoughtful single-window UI.

This is going to be another great year to be a Mac developer. And we haven’t even seen the rest of Leopard yet. Only bump in the road will be if iPhone is a closed platform. The comments over at Theocacao provide some interesting commentary on that question.

Last year I started some extra work to help bring DigiCel FlipBook to the Mac. FlipBook is software for traditional, hand-drawn animators, and it is actually somewhat unique in the industry. Whereas Flash and Toon Boom are vector-based, FlipBook started life as pencil test software for paper-based workflows. It supports scanning with peg hole auto-registration, camera capture, or drawing with a Wacom tablet.

Customers had been asking for a Mac version for a while, but the initial port from Windows to the Mac was not quite ready. It was missing QuickTime support for import, export, and video capture, and the Win32 compatibility layer was somewhat of a roadblock to a polished Mac product.

I entered the project and ended up re-architecting the application to have a more Mac-like appearance. Instead of using the Win32 library, I wrote a lightweight MFC implementation entirely in Cocoa. MFC is Microsoft’s C++ framework, still widely used even with .NET and C# pushed for new applications. This approach allowed the application to be driven almost purely from Win32 and MFC, but it uses NIBs for all windows and controls because the compatibility framework sits at a much higher level. In several places the Windows code peeks through, but it provides enough flexibility that more and more of the application could be upgraded to a modern Mac look and feel while still sharing a common Windows codebase.

The idea is that by working at the MFC level instead of Win32, you can get by with implementing only a very small subset of the full Microsoft frameworks. If the app only uses a few basic control types, for example, you only need to wrap those onto their Cocoa counterparts and can ignore everything else. (Otherwise you end up rewriting all of Win32 just to load and run the unmodified MFC sources.) Even with that simplification, though, the truth is that I seriously underestimated how much work this would be.

The stack for this ends up looking something like this:

It has been an interesting project, both for the technical challenges and because animation is near to my heart. I plan to use the software in my own personal film projects. Here’s a screenshot of the latest version.

I write Mac software, but over the last year I’ve increasingly been building Ruby on Rails web apps as well. Today I finally took a look at “RubyCocoa”:http://www.rubycocoa.com/. I wanted to whip up a quick Cocoa app that would involve some text parsing, and a dynamic scripting language like Ruby is a much better fit for text processing than C, C++, or Objective-C.

It turns out RubyCocoa works amazingly well. I have only scratched the surface with a small test app, but I was blown away by its ease-of-use, Xcode integration, example projects, and apparent maturity. You have full access to AppKit from Ruby-based controllers and views, and a single NIB file can even reference both Objective-C and Ruby classes. Fantastic stuff.

I don’t know if it’s ready for commercial software use yet. For distribution, I tested including the RubyCocoa.framework inside the application package and the app launches and runs correctly on a system without the full RubyCocoa install. There may be issues with requiring a recent version of Ruby, but otherwise it’s a fully native app.

My only disappointment was in the Objective-C calling conventions. There are two versions to choose from: a style using underscores to separate named values, and a slightly easier Ruby syntax using symbols and extra parameters. Here they are:

Objective-C:

[my_window setFrame:r display:YES animate:YES]

Ruby Underscores:

my_window.setFrame_display_animate(r, true, true)

Ruby Symbols:

my_window.setFrame(r, :display, true, :animate, true)

In my opinion, a better approach would be to take advantage of Ruby’s trick of allowing the last parameter to be a hash supplied without the curly braces. This feels more readable to me and more closely matches the Objective-C equivalent.

Better:

my_window.setFrame(r, :display => true, :animate => true)

In any case, that’s a minor complaint and doesn’t take much away from the beauty of writing native Mac apps in Ruby.

I started reading the electronic version of Eastern Standard Tribe. Hoping to get through some of it by SXSW and pick up a hard-copy there. I’ve also been reviewing my Cocoa books, since I’ve been porting the user interface of an application to Cocoa (still lots of Carbon and cross-platform C++ underneath). More on all that some other time.

For now, here are two somewhat contrasting quotes from the authors of those books, on file format standards:

Matthew Thomas’ “When good interfaces go crufty” is a fun read. It’s nothing we don’t already know, but sometimes it’s helpful to be reminded that some of the interfaces that we are so used to are still confusing for new users. His talk on the evils of using file paths to reference files and applications is resurfacing in the Mac world, as a new crop of Cocoa-based applications generally ignore using aliases (not alias files in the Finder but the AliasHandle toolbox type to keep track of files that might be moved or renamed out from under the application). Try this test in BBEdit, then in Apple’s TextEdit:

Make a new document and save it on the desktop.

While the document is still open, rename it in the Finder.

Go back to the open document, type some more text, and click save again.

When I tried this with OmniOutliner, I expected it to perform as poorly as TextEdit. Instead, OmniOutliner does recognize the change and updates the document’s title bar with the new name. But then it ruins this intelligence by asking the user whether they are sure they want to save with the new name. It’s as if OmniOutliner is bragging — “Hey look at me, I’m so smart I noticed that you renamed my file”. Applications shouldn’t need to show off, and the ones that just work as expected will usually be more enjoyable to use.

It’s fun watching the posts come in to the Mac OS X Conference “Trackback” feed. Hopefully more people will hook into it before the conference is over. It’s a good way to learn about other blogs that share a common interest.

MacCentral has a short write-up on James Duncan Davidson’s Cocoa talk at the OS X conference. One quote that stood out for me: “Project Builder was the first IDE I actually liked”. That’s funny — the more I use Project Builder, the less I like it.