On November 8, Apple released the new MacBooks with a Core 2 Duo CPU. Typically, Apple takes weeks (sometimes even months) until they publish the developer specifications. With the MacBook, it only took two days. This enabled me to quickly slip in support in the 1.5.2 release.

Or so I thought. According to Apple, the new MacBook had a model identifier of MacBook1,2. It did seem peculiar that they didn’t call it the MacBook2,1, but I figured changes were maybe not notable enough to warrant such a major bump. In any case, I added 1,2 to MenuTemperature’s list, and released it. Over the next few weeks, though, I got reports that it wouldn’t work.

A quick web search confirmed my suspicion: there is no such thing as a MacBook1,2 (the results don’t represent the query), but there certainly is a MacBook2,1. The first person to report it received a replacement file from me, but never responded whether or not it worked. trac might be to blame, in that its notification of ticket changes is quite lacking.

In any case, 1.5.3 is now out, and hopefully, I actually get positive reports of it working now. Meanwhile, Apple still has yet to fix their specifications. Yes, I did send in a report.

Go get it!

I’ve also discussed the design a little more with Shoom’lah, whose pen-with-book design proposal is (aside from being the only one ) well on its way to become the new identity of ML. The logo is unique, recognizable, somewhat scalable and rather cute. It’s also reminiscent of Myst’s original icon (which, aside perhaps from a few slight tweaks, has been reused in Uru, too), and she and I agree on which of her four proposed color themes is the best (I’m deliberately not saying here since I’d rather have some additional, unbiased input!).

What else? No, that’s pretty much it. In the past 12 days, we’ve averaged 166.58333… contributions a day, which is very impressive and well above my expectations (which is generally the case with pessimists like me, but that’s besides the point ).

The support namespace has barely been worked with yet, and we’ve added another (based on an idea of mine and Tay’s; yes, sorry Tay, I had it first, I just never got around to thinking about it much ) namespace for walkthroughs.

This is extremely exciting for me.

MenuTemperature 1.5.2 is out too, now with French again, and already with Core 2 Duo MacBook support — Apple released the developer specs unusually early.

A lot of the work on this release wasn’t even done by me, but by Sam Rushing (thank you). As I’ve argued yesterday, it feels a little like giving a child away, letting someone else parent it, then receiving it back. You still love the result, but somehow, it just isn’t the same. I think it’s important that I get away from that kind of thinking. Not in a “it’s just a piece of software” way, but in one where everyone can contribute.

With MYSTcommunity, I often felt similarly. Should I let other administrators make many decisions on their own? Or should I always have the ultimate say? Which is right? And which benefits the members more? Clearly, the members benefit more when the founder isn’t egocentric and knows when to step down. So eventually I did, and observed the project at more distance, only to return with regained strength. I think that was great. It could have made me feel disposable, not unique — any other person could be an admin. But that’s not really true: many others could be (hardly anybody), and each one of them would have done it slightly differently. Perhaps better, perhaps worse, but certainly not quite how I would have done it — and not necessarily in a way I would have approved of.

In other words, I don’t like everything MYSTcommunity has become, and I don’t like everything MenuTemperature 1.5, but learning to deal with that is an important lesson of life, and a good one.

Dealing with Rushing’s code and retrofitting it was not a reason for the delay. I didn’t do that. I don’t agree with everything he has done, but I won’t do his code the disrespect of changing it around just for the sake of changing it around. That would be the very egomaniac behaviour I described yesterday, and negatively so. Eventually, Rushing and I were done working on it; my last actual code changes were around September 9. What delayed it was a wrong decision of mine.

I try to make my version numbering as simple yet logical as possible. I don’t use 0.* versions, because I find that they are usually a give-away that the developing team as far too vague ideas of what 1.0 should be like. And, more to the point, I try to never add notable features in point releases (x.y.* ones). This is not just beneficial for users — they’ll immediately see that an update focuses on bugfixes or other minor changes, rather than actually introducing soething new — ; it also has major project coordination advantages.

One became very visible once I had released 1.0: I was contacted by someone with a French localization. And then, after 1.0.5, I was contacted by someone else with a Traditional Chinese one. But if 1.0.0, 1.0.3, 1.0.5 and everything in between had had ever-so-slight differences in their feature set, it would have been necessary to revise, or perhaps completely re-do those localizations. That doesn’t just mean unnecessary work for the translators: it also means, as I have now found out, that you have an even harder time shipping an app when you intend to.

Because, once 1.5 entered beta stage, it was feature-complete — localizations could already be made; changes would only be under-the-hood, in areas not intended to be visible to users. So I contacted the French localizer, who assured me there would be a translation soon.

I don’t want to do him any discredit; he’s a very nice guy, and I genuinely and greatly appreciate the translation work he’s done. He’s probably just busy, or perhaps he forgot — it doesn’t really matter. The point is something completely different: I made the mistake of relying on someone else before shipping. That’s great when you have regular, frequent contact with them, but I don’t. I can contact Rushing several times a week, or amon-re, who does the occasional testing for me, or several others. But my localizers, for MenuTemperature as well as DashPrefs, are people I don’t know; they do their stuff, e-mail me, I respond back to thank them, and that’s pretty much it.

Bottom line: not only should you not rely on a deadline you’ve made yourself, because you won’t meet it anyway (cf. yesterday’s posting). You also should not rely, at all, on too unpredictable factors, and in this case, localizers who aren’t organized in a team and who you barely have any contact with are far too unpredictable.

So the end result, and I don’t really like it, is that 1.5 is shipping with fewer localizations than 1.0.6, which I’ve also released today. 1.0.6 does German, English, French, Dutch and Traditional Chinese. But 1.5, while having many more features only does German, English and Dutch.

When a release whose main rationale are new features lacks a feature its predecessor had, that’s quite ironic, and sad. It also means that some people using 1.0.x in French or Traditional Chinese will update to 1.5 only to find out that it doesn’t come in their language any more, and the downgrade is nowhere near as simple and automated as the upgrade.

Make no mistake: shipping an app is hard. No matter how prepared you are, you will make mistakes. And while writing this, yet another occurred to me.

MenuTemperature adds many features that will be immediately obvious to you, such as the added display of the frequency — either next to or underneath the temperature, or even in place of the temperature. It extends the previous support of a 10-minute average value with a 10-minute maximum and minimum, as well as all the three for all-time values.

1.5 also provides an external window, giving you quicker access to all that data, which many have requested as a useful alternative view. This window lets you export the data by copying to the clipboard, or by saving to a file.

You have greater flexibility in changing the update frequency, replacing the slider with a text input field and a stepper. The preferences also now let you add or remove MenuTemperature from the login items easily, and they give a new option (the new default setting) for taking the preferred temperature unit straight from your International settings — if you generally use U.S. units, you’ll get Fahrenheit, and if you have Metric set instead, you’ll get Celsius. (You can still manually override this, if you like.)

Especially for Intel users, the improved installation and added deinstallation of the SpeedIt kernel extension will be of use. We now provide a LaunchDaemon that will start SpeedIt automatically; editing the /etc/rc file is fortunately no longer necessary. We also add an uninstall menu item that will easily remove the kernel extension (and the LaunchDaemon) as well as, optionally, move MenuTemperature itself to the trash.

Finally, we have completely rewritten the way gauging works, making it significantly more efficient both on Intel and on PowerPC, and have in the meantime added support for several more models. Even more model support is coming by the final, and additional support will be easier to add.

Despite all this, MenuTemperature 1.5 has remained virtually the same size as before. The 1.0.5 bundle takes up 940 KB, whereas the 1.5 Beta 1 one, currently lacking two localizations, is 888 KB, so it will likely end up at a very similar size in final.

It’s been about two months of work, and I’m thinking it was well worth it. It’s a solid update that adds many requested and other features, yet makes the application more efficient overall and doesn’t come with bloat.

The 312 KB zip archive can be had right here. The usual beta caveats apply.

P.S.: Localizers, here’s your chance to have MenuTemperature translated to your preferred language in time for the 1.5 release!

• Sparkle 1.1.
• Solved a problem concerning paths with spaces.

Also, if things go as planned, this will be the last release on my site. Captire now provides a new home for MenuTemperature, which will eventually allow it to grow more.

So, go ahead and download it here.

There’s also other kinds of spam I suffer from. Luckily, virtually no IM spam, which I’m actually surprised about, given that I publish my IM addresses rather publicly. But, for instance, blog comment spam. Akismet brought near-perfect detection, but I’ve found even that to (somewhat inexplicably) have false positives, so I added Did You Pass Math?, which is like a captcha, except it doesn’t come with annoying illegible letters and numbers with lots of guesswork involved. It’s quite effective; the spam volume that ends up with Akismet (i.e., goes through detection at all) has gone down from dozens a day to the odd one or two in a week. That’s good enough for me. Sure, you now have to add two numbers together, something not everyone enjoys doing, but it saves me an awful lot of time that I can spend better now.

And then there’s the really crazy kinds, such as spam in a bug tracker. Enter MenuTemperature’s trac. It’s not only full off tickets that are spam entirely; no, it now also comes with spam comments to existing, valid tickets. Worst of all, these spam comments completely mess with the ticket settings! A ticket’s priority, type, version, component and milestone are randomly changed around several times, making it a lot harder to find the original ticket again.

I’m gonna have to find a solution to this, and I hope it won’t involve requiring registration.

• Updates SpeedIt to 0.5. (R130M) This should hope general reliability on affected Macs (all current Intel Macs).
• Adds support for the 15-inch PowerBook (January 2005). (PowerBook5,6) This PowerBook was available in 1.5 and 1.67 GHz configurations and, perhaps most notably, was the first Apple laptop to feature the Scrolling Trackpad and Sudden Motion Sensor features.
• Lastly, 1.0.3 had a slight mishap whereby the version was incorrectly reported as 1.0.2 to Sparkle, causing inaccurate “new version available” alerts. Sorry about that!

Available here.

Plus, I’m actually putting multiple clips together (yay editing; yay no more reading off a long piece of text) as well as inserting a photo of Maik’s — including a snazzy random transition — for the lazy folk who won’t bother going to Flickr.

And I’m gonna talk about how and why MenuTemperature came to be.

That’s all. Go watch.

Your product “MenuTemperature 1.0.3″ has been tested by the Softpedia labs and found to be completely clean of adware/spyware components.

We are impressed with the quality of your product and encourage you to keep this high standards in the future.

Now, this “cleanliness” they seem so impressed about should be nothing special, let alone surprising to me , but the fact that, without me having ever contacted them or submitted something to them, they discovered the app, seemed quite impressive.

They created an information page akin to MacUpdate’s, complete with its own download statistics and, most astoundingly, their own screenshots, so their claim that they have actually tried and used the software, if only for a few seconds, has to be correct. (Their screenshots are reasonably done as well, aside from one thing: apparently they didn’t wait long enough to have the ten-minute average value show up, hence the “Please wait…” menu item. So maybe it was indeed ‘only for a few seconds’. Oh well. )

Their finding of my app doesn’t seem quite as unexpected, however, if you dig a little deeper. For this version, I had decided (well, I was forced, due to a mistake of mine) to use different release notes pieces of texts for the MacUpdate page, and for my own blog post. Guess where Softpedia has theirs from? From the competitor, MacUpdate. Hmm, hmm. I guess they may be spying on each other’s “recently released” lists.

But really, who cares? It’s had 15 downloads at Softpedia, which is a tiny number compared to what I get on MacUpdate, but it helps my work spread regardless — for free, and without even having asked for that.

So thank you, Softpedia. I’m flattered!

Finally, there’s one more performance improvement.

This release does not add more hardware support.

Download it.

I would like the replace the rather ugly “Please wait…” phrase I use in MenuTemperature a lot (when values are expected to be available soon, but aren’t just yet) with a more succinct and simple (and, not requiring localization!) spinning progress indicator. You can see here what I’m talking about. One of those. That page is talking about widgets, but the animation is a decent replication of what Apple’s progress indicators look like (as of 10.2 Jaguar, that is; previously, there were the Mac OS 8-style “chasing arrows”, which you can see here if you scroll down to figure 12).

That would be simple, since Cocoa provides NSProgressIndicator. You can drag one of ‘em into your UI using Interface Builder, then hook it up and off you go.

That, however, only works if ‘your UI’ is a window (or anything similar that can hold arbitrary controls). The main part of my UI, however, is a menu. Whereas on Windows, it is not unheard of (though still unusual) for menus to have a variety of controls, from popup buttons to editable text fields, I’ve never seen this on Mac OS, for better or worse (decide for yourself). I assume this simply isn’t allowed with the typical APIs, and — if at all — is only possible with an amount of hacking so significant that most developers (to the user’s fortune, if you ask me) will give up. We conclude this slight(ly misplaced) comparison now to get back to the topic, and to the problem.

In this particular rare case, it would be beneficial to have this ability. So what do we do?

It turns out the solutions (or, the availability of solutions) differs depending on whether we want to edit the status item (i.e., the “menu header”) itself, or the menu items within the menu underneath.

One solution that possibly works for both, since all we really need is an animated set of images here, is to use NSImage and display that. But that’s, frankly, rather lame. Sure, it gets the job done, but I’d rather avoid it.

Another way, apparently, would have been to interact not with the NSProgressIndicator class, but its cousin, NSProgressIndicatorCell, except that class doesn’t exist. As seen in Apple’s “Application Kit Framework Reference”, quite a few classes have “Cell” sister classes. There’s NSDatePickerCell for NSDatePicker, NSLevelIndicatorCell for NSLevelIndicator and NSTokenFieldCell for NSTokenField. At the same time, however, there are many classes without such a complement. amon says that, once you have a “Cell” class, you can usually embed it somewhere rather easily — unlike a “View” class.

Pretending the class exists yields about half a dozen results at Google, obviously echoing my wish that Apple had implemented this.

Which leads me back to NSProgressIndicator itself. Didn’t I see exactly what I want somewhere?

Yes: in Automator. When you execute a workflow, the status bar will indicate progress, showing the current task as text as well as a spinning progress indicator, plus a little stop button.

That button is simply drawn using NSImage, setImage: and pathForImageResource:, as a strings /System/Library/CoreServices/Automator Launcher.app/Contents/MacOS/Automator\ Launcher | grep -i image can verify. Fair enough. (Interestingly, the menu is displayed using NSStatusItem, rather than NSMenuExtra, which Apple almost always prefers to use — cf. my previous discussion of the differences.)

But the spinning wheel is not an image. Not only are there no such images in the bundle; the same usage of strings also reveals the usage of NSProgressIndicator as well as its methods startAnimation: and stopAnimation:. Rather typical use.

How? An NSView gets created, and, instead of setAttributedTitle: and setImage:, NSStatusItem’s setView: is called. Simple. Doable.

But, alas, NSMenuItem doesn’t have a comparable method. It has setRepresentedObject:, which the documentations state can be used in conjunction with NSView, but as to what exactly that does — seem there’s a lot it can do — , I’m just not sure. What does “representation” entail? It seems to be an alternative to setting an “action”, which would be a far cry from what I need, but I’m not sure. For that matter, what is a “tag”?

(In a “D’oh” moment of writing this, I found out that my - (void)replaceActionlessMenuItemAtIndex:(int)index withNewTitle:(NSString *)title; method effectively has much less use than I had previously thought. I can replace its current implementation:

	[theMenu removeItemAtIndex:index];
	NSMenuItem * item;
	item = [[NSMenuItem alloc] initWithTitle:title action:nil
		keyEquivalent:@""];
	[item setTarget:self];
	[theMenu insertItem:item atIndex:index];
	[item release];

with this:

	[[theMenu itemAtIndex:index] setTitle:title];

Go figure. I’m not sure what had made me think to begin with that existing items’ titles cannot be changed.)

To summarize, I could implement this for the menu’s header itself, which is a nice start. But for the menu items, I’m going to have to find a different solution. Perhaps I’ll simply not populate the relevant ones at all until data is there.

For now, though, I’m off adding another feature for MT.

Could you make it movable? For example, I would prefer it to be closer to the processor and RAM menu (MenuMeters).

In Mac OS X 10.1 “Puma”, Apple introduced a feature they called “menu extras”, similar to a previous frequently-used ability of Mac OS Classic. This feature, effectively replacing the “Docklings” in 10.0 (which, since then, have hardly been used any more by any vendor), enabled developers to place status indicators in the right side of the menu bar. Apple used (and continues to use) this extensively for the clock, the battery indicator, and similar items for volume, AirPort reception, user switching and other items. They also, however, apply it for application-specific features, such as for iChat’s status.

Naturally, third-party developers are eager to utilize this technique themselves. For example, Adium does in a manner similar to iChat. However, third parties don’t get the same level of access Apple internally does. Why is that?

There are two different APIs that serve almost entirely the same purpose. One, NSMenuExtra, is a subclass (or, depending on how you look at it, a superset) of the other, NSStatusItem. The latter – NSStatusItem is publicly-available and, as such, the one third parties are encouraged to use. Apple, on the other hand, makes use of the first, instead: NSMenuExtra. For the sake of brevity (even though this isn’t technically correct, per Apple’s lingo), we’ll call items that use NSMenuExtra ‘menu extras’, and we’ll call items that use NSStatusItem ’status items’.

Although they are virtually identical in appearance, there are a few striking differences:

1. Menu extras can be moved around. If you press and hold the cmd key, you can drag around menu extras as you see fit — inside the space of other menu extras, that is. You cannot place a menu extra to the left of a status item, but you can place it to the left and to the right of another menu extra. Status items cannot be moved around. The same trick doesn’t work, nor does any other. A developer can try and set a status item’s priority (and allow the user to change that somewhere in the item’s preferences), but this doesn’t work reliably, nor is it sanctioned by Apple.
2. Menu extras can be removed. Again, press and hold the cmd key, but this time, drag the menu extra below the menu bar and let go. A little ‘poof’ effect will appear, and out the item goes. Status items cannot be removed. This, too, won’t work on a status item. Instead, status items usually have a Quit command somewhere in their menus. No ‘poof’ effect either (not that that’s relevant).
3. Menu extras can be navigated between. Click and hold the mouse button onto a normal menu, or onto a status item. Then, move to a menu extra and in between menu extras. You don’t have to keep unpressing and clicking again. However, you cannot navigate back to a normal menu, nor do a status item; you can only move within different menu extras now. Status items cannot be navigated between. Click and hold the mouse button on a normal menu, or a menu extra, or even a different status item, and now try and navigate to another status item. Its menu won’t open.

We’ve got three things menu extras can do which status items cannot do. Clearly, menu extras are the more powerful API. Why would Apple not provide these small, but unobstrusive and useful features to everybody? Competitive advantage?

Perhaps laziness is a better explanation, but I’m going to go for ’stability considerations’.

That’s not to say a menu extra is inherently less stable than a status item. One is just as stable as the other. They suffer the exact same amount of potential flaws caused by a developer’s mistakes. It’s just that one is more problematic than the other.

To understand why that is, and to also explain why menu extras actually do have these additional features (and why status items couldn’t possibly have them in the current implementation), we’ll have to dive down into how menus are done in Mac OS X.

Menus are executed within the space of a process.

Big-whooping-doo, right? I doubt you’re surprised.

But if you actually think about it, it answers a lot of questions. What process’s space? The Apple menu, and all menus up to and including the Help menu, are in the space of the process currently running. Personally, I disagree with including the Apple menu there, because, with one exception, none of its menu items are actually specific to the frontmost process. That one exception becomes apparent when you hold shift while in the Apple menu. Force Quit OmniWeb, Force Quit Skype, Force Quit (whatever it is you’re currently running — this item depends on the knowledge what application is currently being primarily interacted with.

But there’s other ways to find out. I think the Apple menu should be implemented in a separate process. There is one benefit to it: if the frontmost application is hanging (e.g., beachballing), you cannot currently access the Apple menu; it hangs with it. If it were in its own process (or in a more general one, such as loginwindow or SystemUIServer), this could be solved.

I’m sure Apple has their reasons for this choice, however — even if the primary reason is laziness.

More important, and less obvious, is what process space the status items and menu extras ‘live’ in: the status items all live inside their own spaces. Adium’s status item lives in the space of Adium. MenuTemperature’s status item lives in the process space of? Exactly, MenuTemperature. But what about menu extras? They all live happily together in a shared space, namely that of SystemUIServer. This includes, although it doesn’t much behave like a menu extra, the Spotlight icon in 10.4 Tiger. But more importantly, it includes all the menu extras, with all their extra beneficial-for-the-user features: moving them around, removing them, and easily navigating between their various menus.

And the reason you can easily navigate between their menus is that they are menus of the very same process, i.e., the very same background application! It’s just like navigating between an application’s menus. The reason you can drag them horizontally to move them, and drag them vertically to re-move them is that SystemUIServer handles this.

But these advantages come at a big price. If Apple were to allow any developer to use their API, there would be a flood of menu extras, and some of them won’t be well-written, and, as such, not very stable. If that sounds like an acceptable compromise to you, consider this: because all menu extras run in the same process space, one menu extra that crashes causes all other menu extras to crash as well! Including Apple’s, and including those from other innocent developers. Not only a nuisance for the user (and coupled with potential dataloss) — though SystemUIServer knows to relaunch itself automatically upon crashing — , but also leading to confusion: for the user, it is completely unclear how and why all menu extras suddenly disappear. And here’s Apple’s biggest problem: the user is more likely to believe that this is a problem with Apple’s code, than that it is a problem with third-party code.

Apple’s current solution of two separate APIs isn’t a good one. It’s not a satisfying one — neither for the user of status item-based programs, nor for the developer who makes them. But it’s a good compromise for the time being, until Apple finds a way (if ever) to implement status items that have the same features as menu extras, or to implement SystemUIServer in such a way that it can handle one menu extra crashing without affecting the others. But much like a kernel extension crashing often causes the entire kernel to go down, there probably isn’t a reliable way to have a process’s plug-in’ crash not affect the entire process.

There are ways for a developer to use the NSMenuExtra API. There is, as such, a way to enable users to move MenuTemperature around, or to remove it using drag & drop, or to navigate its menu like any other. It has worked well for MenuMeters to crack into Apple’s API. And there’s a public tutorial on the web to do it yourself. But still, this is strongly discouraged, and perhaps if I were more well-versed, I’d risk it, much like MenuMeters does. While I’ve never seen a released version of MenuTemperature crash, let alone negatively affect other applications, I’d rather not tap into this space of uncertainty. For Apple’s sake, for the user’s sake, and ultimately for my own sake as well.

If you are a developer, and want to implement it in MenuTemperature, please feel free. I won’t guarantee I’ll add this for official releases (though I’ll definitely keep the option open!), but at the least, we can have a separate version that does this.

If you are a user, and want MenuTemperature and other status items to have the ability to move around, as well as other benefits, the best you can do is to kindly ask Apple. I’m sure they’re already aware that this is useful, but maybe they don’t know just how many people would have to have this. Or, you can ask a developer to implement this in MenuTemperature. Just don’t ask me — I’m too new to this and would rather not risk it.

(To tell you the truth, the very writing of this encourages me to give it a try, but I still think I shan’t. )

Changes

• Added support for 2 more machine types. For one, the original Power Mac G5, of June 2003, and its added sibling in November 2003. These identify themselves as PowerMac7,2 (strangely enough, it appears there never was a 7,1). The other machine is the last revision of the iBook G4 (PowerBook6,7), released August 2005 and distinguished by its Mobility Radeon 9550 (rather than 9200).
• While the mouse is being held down on the frequency slider, the timer is now delayed. This yields quite a discernible performance improvement if you ’scrub’ with the slider to figure out just the right interval you want. Previously, every time the slider value changed, the timer would fire again; now it only fires once you’re finished dragging.

Known Issues

• On a Power Mac G5 Quad, temperature gauging may not work. Instead, you will see an artificial temperature of 0 degrees Celsius (or 32 degrees Fahrenheit). Unfortunately, I have conflicting reports on this; one claims it works perfectly and another claims the opposite. I have yet to come to a conclusive reason for this behaviour. If you own a Power Mac G5 Quad, please report back on your experiences. A typical operating temperature is around 40-45 degrees Celsius (though it can, of course, vary greatly — but certainly not go as low as 0 degrees!).

Download it here.

This is not a recommended update. It’s called an alpha version for a reason. This is also not intended for mention on MacUpdate, nor on comparable sites. Use it at your own risk. Better yet, use a version from the stable 1.0 series.

This 1.1 alpha, compared to the 1.0.x versions, adds various features:

• In addition to the ten-minute average temperature in 1.0, ten-minute minimum and maximum are calculated, as well as total (all-time) minimum, average and maximum. “Ten minutes” are also calculated in a much more accurate, albeit more RAM-intensive manner. (Every value is now connected to a time stamp. Previously, a guess for ten minutes was calculated from the amount of values divided by the interval at which values are created; the main flaw of that technique, amongst others, was that the interval could be changed by the user.)
• An “External Window” gives you a nicer overview of collected values, and allows you to copy the results to the clipboard, or save them as a text file. Finally, the window shows you how long MenuTemperature has been running. I figure the latter is useful to give you an idea of how useful the values actually are. E.g., it may either remind you in a positive sense that you’ve been running it for days, or in a negative sense that you just launched it a while ago (because you had to restart, or for whatever other reason), and that values thus haven’t been collected for long enough to your liking.
• The temperature unit can now be retrieved automatically. There’s a per-user system setting for whether you prefer Metric or U.S. (Imperial) units, and MenuTemperature can now leverage this. So, if you set the unit to “automatic”, which is the new default, things will most likely already be the way you’d want them to be.
• On Intel Macs, the frequency can now be measured as well. As of alpha 1, however, this is not implemented for permanent values yet (min/avg/max, 10-minute and all-time), nor does it show up in the external window (or its reports). This value can currently only be seen in the menu bar itself. You can opt to display just the temperature, just the frequency, or both. You can also opt whether you want the two arranged horizontally or vertically: in that case, the font size is reduced to 9 pt (at most) and made bold, for significantly increased readability.
• Various performance enhancements. For example, on Intel Macs, all the gauging is now done in C, rather than with help of shell scripts. This is significantly faster and less heavy on the CPU. After all, taxing the CPU too much would needlessly dilute the very values you’re trying to get!

Notice that this version doesn’t come with updated localizations. Some stuff (such as the Credits file) is, in fact, older than what you’d get in 1.0.1. Since this is an alpha, it frankly doesn’t matter. This is being released for testing only, not for general use. Please do feel free to file bug reports; set the “Version” to “1.1alpha”.

So, if you can promise you won’t spread this around, complain about problems in it or caused by it, or judge MenuTemperature’s general quality by it, do give the alpha a try. Otherwise, it’ll only be a matter of weeks until this is final anyway.

The download link.

• Added support for 9 more machines, for a total of 13. In addition to the Power Mac G4 MDD, the June 2004 Power Mac G5, the 2004 iMac G5 and the 15-inch MacBook Pro, we now support the Late 2005 Power Mac G5 (including the Quad), the April 2004 and October 2005 15-inch PowerBook G4s, the 2005 12-inch PowerBook G4 and every current Intel Mac, i.e. every Mac with an Intel Core 1 Solo or Duo (“Yonah”) processor.
• The timer now disables during sleep. When the machine is about to go to sleep, MenuTemperature now stops polling. When the machine has woken up, polling resumes. This will hopefully fix sleeping issues which some have experienced.
• Various minor performance optimizations and other enhancements.

If someone could provide more localizations, I would gladly add those.

Here’s the download.

P.S. (this is only relevant for users on Intel Macs): As someone has pointed out, MenuTemperature currently doesn’t work well if you have set it to launch on log in, unless the SpeedIt kernel extension is already otherwise running. This will be fixed in a future release. For the time being, I recommend in this case that you add the line

kextload /Library/Extensions/speedit.kext

to your /etc/rc file, before the last line, so the end of the file should look like this:

touch /var/run/.systemStarterRunning

if [ "${VerboseFlag}" != "-v" ] ; then
        /usr/libexec/WaitingForLoginWindow
fi

kextload /Library/Extensions/speedit.kext

exit 0

You will need to authenticate in order to save this change. After a reboot, SpeedIt should run automatically, and MenuTemperature will recognize this and no longer ask for a password.

The 1.0 series of MenuTemperature is supposed to be a minimalist, does-the-job release. That is, it doesn’t come with a lot of features, but it completely fulfills my original requirements — and more.

For those who haven’t been following or are new to this site, MenuTemperature is a small Mac OS X utility for measuring your computer’s CPU temperature. It provides the 10-minute average of measured values as well, and lets you set the frequency (interval) at which gauging takes place. The current value is displayed prominently in the menu bar, as a status item, although you can decrease the font size if you find it too distracting, or if it simply takes away too much space. Either Celsius or Fahrenheit values can be displayed.

For MacBook Pro owners, SpeedIt, a third-party kernel extension is used, because access to CPU temperature values is not currently otherwise possible.

MenuTemperature supports Sparkle, which means you don’t have to worry much about missing out on new versions — you are notified, get to read the release notes if you wish, and can automatically have it download the new version and restart the application, making the often-tedious process of keeping your software up-to-date rather seamless. Or, you can manually check my Projects page, which will always point out the latest versions.

Obviously, quite a few features are planned for the future, so if you have ideas, they may already be in the works — nonetheless, I do of course highly value any feedback. Positive, negative, but hopefully constructive. Tech support is primarily handled, too, through the comments field below — keep in mind that your question (and answers to it) may be of interest to other readers as well. That said, you may, of course, contact me in private, but I cannot guarantee any response times at all.

MenuTemperature only works with machines of users who have provided me with information on how to retrieve the temperature values. If your machine isn’t currently compatible with MenuTemperature (there’s a high probability of that!), I rely on your feedback. Usually, that boils down to reporting the results of ioreg -lw 0 and sysctl -a to me, as well as the machine code (which you can retrieve from System Profiler, and will look something like MacBookPro1,1). Again, I can only do this by getting this information from actual owners of the machines!

For bugs, as well as reports for your specific model (see preceding paragraph), you can use trac’s new ticket page. Naturally, do try and search for existing tickets first; maybe your issue or information is already mentioned.

I’m providing this software in the hope that it will be useful to you. It is available for free, including the entire source code (available under the MIT license, via the Subversion repository or the trac project site). Donations are appreciated, but even more so, like I said, I welcome your feedback.

Download it here!

Oh right, the download link.

Update: I had previously uploaded a version that identified itself as 1.0b8, despite being 1.0b9. Simply run Sparkle’s update check again to remedy this.