Richard Buckle has released a new version of decodecrashlog.

decodecrashlog is an open-source, BSD licensed Python program that can apply a CodeWarrior CFM link map to a Mac OS X crash log from a "release build", recovering the function names and offsets.

John Siracusa’s Tiger review includes a digression about boolean searches, which struck a chord with me.

He says “I think Apple has an insultingly low opinion of users’ ability to understand nested boolean logic. They may not know what it’s called, but the concept is intuitively understood”, and cites a number of Apple’s programs such as Mail and Spotlight which duck this issue by only allowing a single group of tests to be OR-ed or AND-ed, rather than allowing a query that can contain both ANDs and ORs, such as:

(genre is "Anime" or genre is "Game") and my rating is greater than 2 stars

This is something that’s always annoyed me too. Most applications don’t do it, and, I’ve usually found the interface to be pretty poor in the ones that do.

I’ve always thought that the best solution to this problem is to allow the “simple” expressions to be named and saved, and then to allow one simple expression to refer to the results of others. Siracusa actually mentions my approach as a “cumbersome” workaround, but I disagree, I think it’s actually a good pragmatic compromise. In my opinion, the alternative approach of allowing nested expressions and trying to implement an interface which allows them to be edited “in-line” in one big chunk generally ends in tears!

I can see that having to create named sub-clauses is not the fastest interface to use if you want to create a query on the fly, but then I find that any query requiring nested ANDs and ORs is likely to take more than one attempt to get right, and is also likely to be reused, so having an interface that forces you to name the sub-clauses and save them for later is no bad thing.

To illustrate what I mean, imagine a search filter interface which lets the user specify that a rule is true only if either “no test is true”, “any test is true”, or “all tests are true” (in other words, NOT, OR or AND). This is the interface that is provided with programs like Mail, iTunes and Spotlight.

Now imagine that one of the tests that you can specify is that another rule is true. This is the crucial step that is missing from most of Apple’s search interfaces (and lots of others), for no sensible reason that I can see.

The above example would be composed into two sub-clauses:

"Is Anime or Game" if any of the following is true: genre is "Anime" genre is "Game" "Is Good Anime Or Game" if all of the following is true: my rating is greater than 2 stars rule "Is Anime or Game" is true

The advantages of this approach are:

• you have all you need to make arbitrarily complex rules, but at each stage of editing, you only have to deal with one kind of comparison - not, or or and - which can be specified by a pop up menu in a clean way
• there's no nesting, so all the tests can be listed in a vertical list with no indenting or bracketing required
• this approach forces decomposition of a complex problem into simpler steps, which as programmers we know to be a good approach
• by naming and subdividing even relatively simple search clauses, and allowing them to be saved for later, we promote re-use, which turns out to be handy too

For me, just the simple addition of the ability to refer to the result of one rule or filter when defining another would vastly improve the utility of many programs. I’m even quite surprised that Apple hasn’t come up with a reusable interface for this sort of thing. It’s clearly something that would benefit from standardisation (like choosing files does, for example), and it ought to be relatively simple to come up with an API which dealt with displaying, editing, and storing rules whilst allowing application-specific code to be plugged in to implement that actual evaluation of results.

I’ve just noticed an embarrassing error on this site - the software link on the menu bar was doing a search of all blog posts under the software category, instead of linking to the Elegant Chaos Software page as it should have done.

Doh! I’ve fixed it now - apologies for the confusion.

I’ve recently been spending a bit of time working with Apple’s IDE XCode.

It’s a reasonably mature product now, but I have to say I am very surprised at how limited it is in some ways.

The class browser, for example, seems extremely basic - no folding editor, no support for adding new methods and classes, no factoring, and code completion which is not a patch on VisualAssist.

It also doesn’t seem very modular, so I don’t get the impression that there are lots of third party enhancements available to fill in the gaps.

I have spent the last few years berating Metrowerks for allowing their IDE to become so clunky and old. Now that I’ve seen the major competition, I’m beginning to understand why it might be that way!

XCode is not terrible, but it’s crude enough to make me wonder - am I missing something?

I’d also be very interested to hear whether it’s possible to use Eclipse to do Cocoa development on the mac…

In the past, Apple has flip-flopped between two positions:

1) We provide the APIs, you (the developers) write the applications.

We don’t want to tread on your toes by writing products that compete with you, so we will provide only trivial applications, and sometimes we’ll even suppress our own internally developed applications, because they are too good.

This is what did a lot of harm to technologies like AppleScript, and PowerTalk. Apple allegedly had a great Mail client for PowerTalk, and a great editor for AppleScript, but didn’t want to release them for fear of offending the competition.

2) We want this platform to kick ass, so we’ll write some kick-ass applications.

We don’t really care about treading on your toes, because frankly we are the only people who have the whole picture. We know the system inside out so our applications can really integrate with it, and each other, resulting in a really nice user experience.

We don’t want to stop you from developing, but you’d be better off not developing anything too good otherwise we’ll have to do our own version and give it away for free.

Position (2) seems to be the default with OS X, and in some ways it’s hard to knock it. Admittedly some people get hurt along the way (Watson? Konfabulator? Come to think of it, anything that Arlo Rose was ever involved in), but all’s fair in love & war, and to be honest, an out-of-the-box Mac running the stock applications is really quite a nice tight ship these days, so it’s hard to argue with it from a user’s point of view.

It occurred to me today that there is a third way! It’s something that Apple is already doing in many ways, but they should definitely be encouraged to do more of it, and perhaps it should be formalised in some level of the Apple echelons of power.

Basically it’s the WebKit approach. WebKit is the rendering code that Safari uses. What Apple did when they developed Safari was to factor out the actual rendering code, put it into a reusable Framework called WebKit (something that other developers can use), and then build Safari on top of it.

Apple still gets to make a nice tight application that is well integrated with the OS and with other applications, but they also make a large chunk of the “heavy lifting” code available to everyone else. So someone like Omni can come along with their competing browser, and recode it to use WebKit. Now Omni can concentrate on adding the features that make OmniWeb better/worse than Safari (depending on your point of view), whilst offloading all of the support headache of the web rendering code onto Apple.

This approach is great for lots of reasons.

It encourages Apple to push the envelope, because they are doing something that benefits all developers. This is good because there are an awful lot of talented engineers at Apple. They might be working on Fireware Hard Disc drivers in the daytime, but they might well also have a great idea for an improved email client. It’s probably a good thing if those ideas can be expressed within Apple.

It also allows Apple to provide well integrated out-of-the-box solutions for whatever they deem to be the core tasks that an average user wants to perform, which, let’s face it, benefits us all if it means that more people buy Macs.

It lowers the entry point for Application development, which gets more talent into the Mac development space. It’s now feasible for me to write a customised web browser with WebKit. I might not do something very polished without a lot of work, but it might allow me to show you my great idea for browsers, which someone else may then run with.

It also encourages (forces even?) developers to focus on the added value (sorry) that their application is bringing to the domain they are working in, and they’ve got more time to focus on that code. The result for the user should ideally be an application that raise the bar another level past Apple’s default one, rather than just doing the same thing in a different way.

As I’ve said, this has already happened with WebKit, and because of the modular way in which a lot of software is developed these days, it is happening in other areas of the operating system - I suspect as a result of code which Apple engineers develop first for their own benefit, then realise that they can generalise for public consumption.

I suggest, though, that Apple make this a policy at some level. Yes, we will develop a mail client, web client, address book, music player, etc, etc, but each time we do so, we will ensure that the core ‘engine’ is provided as a public framework or API which other OS X developers can use. This will be good for them, and great for us.