MUG 2.6: Release Day Notes

Tuesday, 2006-01-17; 20:54:00

Ugh. MUG 2.6 has been a long time in coming, and I finally released it early this morning (i.e.: late last night). This must have been one of the most annoying releases ever, though. Basically, a whole slew of issues cropped up at the last minute and I stayed up until 5 AM trying to correct them all to ensure a solid release.


First off, I found that using the Process menu items when a history window was frontmost was causing problems. Specifically, the "Kill", "Reveal in Finder", and "Set Priority" menu items were all causing a crash. That was easily fixed.

Then one of my testers, Bryce pointed out that when you selected items in the tables of the Tab or List View windows and then refreshed, there would be a slight delay for each item you previously selected. (MUG does some checking to rehighlight the processes that you highlighted before the refresh, and does it for multiple items under MUG 2.6.) So if you selected 5 or 6 items in the list and refreshed, MUG would take like 2 or 3 seconds to highlight each item in succession.

I realized this problem was related to some OS X 10.1 compatibility code I had introduced, and I verified it by testing for this problem in an earlier beta. The problem was, even after removing the suspect code, the problem was still there! (In case you were wondering, the suspect code was that OS X 10.1 doesn't have a call for the table selection color, so I had to override the NSColor class to implement it for OS X 10.1. But it wasn't causing the refreshing problem. More on this later.) I must have spent over an hour trying to figure out where something was breaking down, and I finally figured out that I had added in some testing code that told the table to redisplay every time the table selection changed, and that was causing the slowdown.

The NSColor extension I had implemented was also bugging me. Since OS X 10.1 didn't have this call, I had to implement it myself, but by using a category, I can't call the original method on OS X 10.2 or later. But the only way I found (at least as far as I know) to fix the problem was to use a category, because I didn't have access to the source code of what powers a table view. (Basically, in Objective-C, a category allows you to extend a standard class to have some extra methods that you implement. You can even override existing methods if you want the class to do something else.)

If you look at the table selection color of a standard Cocoa application, you'll see that this selection color is actually different than the selection color you've selected in the General/Appearance system preference pane. For some reason, there's an "alternate" color used for selecting table views. I mean, it does look better, but it's not obvious why there would be an alternate color. Anyway, I did some investigation and figured out that the alternate selection color is just the selection color with the same hue, 20% more saturation, and 20% less brightness. Good, that means that I can just override the method and use my custom method, right?

Well, turns out that Apple is annoying, as usual. This is true only if your color selection is NOT a preset provided by Mac OS X. If it's a preset, Apple can set the alternate color on a whim. So MUG 2.6 will not use the standard table selection color if you're using a color selection preset. This is particularly noticeable if you use the "Red" color preset (at least under Mac OS X 10.4 Tiger) -- the table selection color using MUG's method turns out to be an ugly shade of red-orange, whereas the standard table selection color for this preset is a nice shade of pink. *sigh*

(If anybody can point out how to fix this problem -- i.e.: retain support for Mac OS X 10.1, while retaining the correct alternate selection color for Mac OS X 10.2 and later -- that'd be great. If I don't override this method, all hell breaks loose on Mac OS X 10.1 as soon as you select something in a table, because OS X 10.1 doesn't have support for the [NSColor alternateSelectedControlColor] method.)

Anyway, in the process of trying to fix the table refresh delay problem, I added some code (using #ifdefs) that I thought would solve the table selection color problem -- it would retain the correct table colors on OS X 10.2 through 10.4, but would create its own color for 10.1 where the method doesn't exist. Silly me, I didn't bother to test these changes until late in the night when I was about to go to bed, and I found that it totally borked MUG on OS X 10.1. So I had to quickly recompile MUG without those changes (and with the wrong selection color bug for OS X 10.2 through 10.4) and reupload the disk image. Note that in order to test for OS X 10.1 compatibility, I have to boot up an old Titanium PowerBook off of my iPod, which can take a bit. :P

Then, it was also pointed out by Bryce that the refresh values for the Tab/List View windows was off. If the refresh value was below 1 second in the preferences, the refresh rate would actually be as fast as possible. Otherwise, the refresh rate would be 1 second less than was displayed in preferences. Turns out I was retrieving the preference as an integer and not as a float, which would entirely explain the problem.

And then he also pointed out that MUG was not completely filling up the Dock icon while reporting memory usage, when it should (because the full height of the icon is 100%). It usually was a few pixels or so off. It was annoying enough for me to try and fix it, and in the process I realized that the CPU usage reporting in MUG was wildly inaccurate! I was retrieving information on CPU usage using a mach_host_self() system call, which reports "ticks" in the CPU. There are 5 variables: CPU_STATE_IDLE, CPU_STATE_USER, CPU_STATE_SYSTEM, CPU_STATE_NICE, and CPU_STATE_MAX. You need to keep track of the ticks in the CPU_STATE_IDLE variable compared to last time you requested the info, and divide that by the number of ticks in the first four variables compared to the last time you requested the info. You're basically keeping track of how many CPU ticks were idle, and how many were used, and then subtracting the ratio from 100 to get the percentage. I accidentally was adding CPU_STATE_MAX into the mix -- I still don't know exactly what this number represents; I'm not entirely sure if it's equal to the sum of the first four variables, because I didn't bother to check.

So now 2.6 does accurate Dock icon CPU reporting.

Website Updates

This isn't the only thing that I had to do last night. I almost always forget that there's so much stuff to do in order to announce the new release. I had to update my product webpage as well as my company homepage (and, in fact, create a whole new page dedicated to MUG for the update mechanism), I had to write some more content for the aging descriptions of my product in MacUpdate and VersionTracker, and I had to write the MUG "newsletter" that I send off to those people who requested it after registering MUG. That alone took about an hour total, which was itself broken up into little chunks because I was scrambling to fix the last-minute bugs in MUG 2.6.

I also had to send out the PR announcements to the news sites that I typically e-mail (MacFixIt, MacNN, MacMinute, others), and that also requires writing another e-mail extolling the virtues of my application and all the new features. ;)

More Bugs

I originally released MUG 2.6 around 2 AM or so, and then was writing the newsletter and PR announcements after that. At this point, I tried testing my update mechanism from MUG 2.5.1. Even though I've updated the information files which MUG 2.5.1 collects to see if there's an update, it doesn't report it. So that means that that feature in that version of MUG was basically useless. (I've done more thorough testing on the updated mechanism in 2.6, and I'm confident that it will report updates in the future.) But that's a big loss, because users may not know about the update, and it isn't exactly a trivial update. Bah.

So after getting to bed at 5 AM, I awoke at around 9:30 AM (I have a class at 11 AM), and checked my e-mail. A couple people were reporting that they weren't showing anything in the "Applications" and "Other User Processes" tabs of the Tab View window. *sigh* I immediately knew the cause of this, because it was something that I had fixed before, but apparently un-fixed when trying to fix a different bug. (The "ps" command-line utility only reports the first 8 characters of any user name, so when I changed the method I used to get the current user's name to a more reliable method, I forgot to truncate it to 8 characters before comparing it with the output of ps.) So I quickly built a new version, zipped it, and uploaded it, and e-mailed the specific users about the fix. I was running a bit late and didn't have time to create a new disk image of MUG 2.6 with the fix, but this afternoon I updated the disk image. If you're having this problem, redownload MUG 2.6.

And finally, there are a couple reports of a crash on launch of MUG. It seems unrelated to the missing executable files (for which I've created an installer package) which aren't present if you uncheck the "BSD Subsystem" package when intsalling Mac OS X.

So, yeah, it looks like I'll soon be releasing 2.6.1, hopefully with a fix for the annoying color bug, a fix for the crashing bug, an official fix for the Tab View problem I described above (because some people might not redownload 2.6), and perhaps support for reporting CPU usage for the G5 Quads to 400% rather than only 200%.

Technological Supernova   Unfiled   Older   Newer   Post a Comment