Via ars technica: MiniMail looks like a useful addition to Apple’s Mail.

If only I could use it where I need it most. Even if I could get my VPN access working (certificates: ugh.), I’d still be limited by Mail’s incomplete support for Exchange. And Entourage is too much of a resource hog.

Oh, what I’d pay for a good VPN configuration app and for good bridges between CalDAV (iCal), IMAP (Mail), LDAP (Address Book) and Exchange Server.

I don’t have nearly as much of a problem with Leopard’s translucent menu bar as most people (if you go by how vocal they get) do. My biggest concern is not the translucency, but the fact that the text is – for technical limitations in the rendering process – antialiased, but not rendered to subpixels.

Perhaps the reason I’m okay with translucency is that I’ve always used relatively low-contrast, smooth, soft and blurry images as desktop backgrounds. Something abstract, perhaps (like, say, Flow, or Bloody Hippy), but possibly also a photograph that doesn’t happen to have too many distracting elements (German Landscape, Denis’s Fog or Fraser Speirs’s Time Travel come to mind as ones I’ve recently used) Given that the menu bar applies additional blurring, lightening, lowering of the contrast and applying a translucent white-to-grey linear gradient on top of all that, not much is left of the already non-distracting background.

As such, while I appreciate his analysis of the text rendering and image filtering techniques, I can’t really help but wonder how in the world Sven would survive with the desktop backgrounds he passes off as examples in his post to begin with: even with an opaque menu bar, that still would still make for a ridiculously annoying can’t-find-a-freaking-thing desktop. Perhaps his examples are deliberately contrived to highlight the potential issues of the (faux) translucency, but I don’t see them as realistic real-world ones.

But I digress. To me, it’s not a big deal. I could be imagining this, but I rather feel as if it makes for a soothing, calming effect.

Regardless of your personal feelings (perhaps you applied the CI_NO_BACKGROUND_IMAGE hack to remove the translucency altogether), there’s apps that don’t use it at all! Either we have an elaborate hack at work here (possibly laying one menu bar on top of another), or there’s a well-hidden setting. Best-known to have an opaque bar regardless of your settings is Aperture, as pointed out by Bryan Bell (via DFLL) as well as by Matt Swann.

Further, though, I’ve found that at least one variant to get a full-screen window and yet slide out the menu bar accomplishes the same. This is not only true in apps supplied by Apple (such as QuickTime Player); for example, VMware Fusion slides out an opaque menu bar while in full screen mode. This strongly suggests that there is in fact an API – however well-concealed it may be – that lets your app request an opaque fashion for the menu bar.

Thus, to expand upon Sven’s criticism:

And the shame here is that the engineers obviously made and effort to find algorithms that make the implementation of the silly ‘transparent’ menu bar idea less painful. That sounds like hours wasted for nothing. Mere damage control. Throwing good thoughts after the bad idea of some manager or art director.

Not only did they put excessive amounts of time into optimizing this algorithm to make the menu bar look translucent yet not actually be translucent (i.e., to mitigate the distraction); they even went so far as to introduce another menu bar that behaves differently. Not just for individual apps (or modes within apps), either, but also for low-performance computers whose graphics cards don’t have the necessary oomph.

All for a highly controversial change to one of the key components (if not the very key one) of the Macintosh UI. That truly is a bit of a shame – surely, more productive areas to work on could have been found.

Ankur Kothari experimented with trying to optimize CTGradient to only cover his particular needs. As he discovered, CTGradient is a rather hefty class, weighing in at about 1300 lines of code.

He went on to try and eliminate all the pieces he won’t need. First down to 200 lines, then just “a little over 100″, “a lean 80″ and, finally, 30. Quite a change. Thus, his conclusion:

Please: When you use other people’s code, don’t put it in without a thought. Go through it, understand it, and optimize it for your specific need. For the better performance and reduced RAM usage, computers will thank you.

And yet, this wasn’t quite met with unanimous applause. To understand why the notion of cutting down a class like this can be misguided, let’s review why CTGradient was, at the time, created to begin with. It was first introduced in January ‘06, and the first three paragraphs lay out the rationale for the existence of this class:

While [Core Graphics] is a heck of a powerful library… It always seems to take an elaborate amount of code (as well as time, if your not yet acquainted with it) to do some of the simplest little things. [..] AppKit provides a pretty decent layer of abstraction, but I find that there are still a number of holes in its coverage. [..] One of those that AppKit doesn’t cover (that it really, really should [..]), are gradients.

So. CTGradient does not provide new functionality; rather, it exists expressly as a simple abstraction to existing functionality that Core Graphics already does expose. This is a crucial point: CTGradient is purely there to make life easier for developers. Similar classes exist for different purposes. A typical application easily ships with a dozen of third-party classes or entire dynamically linked frameworks, whether it’s custom user interface controls, a parser for a file format, or client functionality for a common network protocol. Why? To save the developer tons of work that someone else has already done.

And it is for that precise reason why Ankur’s postulation is so absurd: if developers were to spend the time he did cutting down classes like CTGradient to the extreme where they only have the code they need, they might as well just not use the class at all. That is, in this example, they could just have called CG* functions directly. That they didn’t do so doesn’t mean they screwed the user over; it means they focused on different aspects of their piece of software.

Does it ultimately cause bloat? Yes, in a sense. There is no denying that plenty of virtual memory could be saved through this process. It’s empirically measurable. But:

• OS X’s memory management is excellent and really couldn’t care less if you’re using a few Megabytes more or not (and it’s not going to affect the amount of physical RAM used in any meaningful way). More or less the same is true on Windows Vista (but not on XP).
• Ankur is going to have a hard time proving his assertion that this will lead to “better performance”. (From what? The code is never called, so how could it impact the CPU or GPU in any way?)
• Whatever amount of time developers didn’t spend “optimizing” the code (or figuring out how to write it themselves) they get to spend implementing features, fixing bugs and interacting with the customer.
• Using someone else’s publicly available code benefits from occasional improvements, possibly from a community of other third-party developers who might fix bugs and add features. Try that with your own home-rolled code in a monolith of an app.

So is code bloat bad? Sure. Nobody benefits from that. However, there’s something even worse than abundance of code bloat: lack of pragmatism. I’d take an app that ships any day over one that is hung up in development hell due to developers who try too hard to make it perfect. I believe any self-respecting developer ought to normally do the same. ‘Normally’, because, there certainly are cases where these issues are more relevant – performance-critical apps in space shuttles, stability-critical ones in nuclear power plants, and so on. But none of that have anything to do with drawing a gradient.

It is even possible to compromise on the two: you could use a script (say, a Makefile) that generates a cut-down version of a class like CTGradient using given parameters – similarly to how ./configure does it for compiled code. For instance, a gradient class could have an –linear-only argument when you’re never going to work with other types of gradients, such as radial ones. But still, the question remains whether the benefit in resource usage outweighs the additional effort required to create, maintain, customize and use such a hypothetical script.

Now, nothing I’ve said above is any new revelation, and all of it could have been expressed in comments to Ankur’s post. Unfortunately, as Jonathan thoroughly discussed, Sir RixStep apparently preferred to turn the discussion into a venue for once again displaying his lacking people skills. It’s a shame, because I think Ankur’s post did make for an interesting read, regardless of whether I agree with is conclusion.

While Hex Fiend is technologically impressive (”It’s been tested on files as large as 118 GB.” says it all), 0xED has what appears to be a superior user interface, as well as a plug-in architecture allowing you “to display and edit your custom data types”.

Via an fscklog entry on a completely different subject.

Jens (Stickies, iChat, Safari RSS, etc.) ponders using Core Animation subclasses to integrate a physics engine.

In the comments, Gus suggests Chipmunk in Box2D’s stead.

Even if that’s all too technical to you, you can’t tell me you don’t enjoy this demo (though it gets a tad repetitive towards the end)!