MacFixIt’s scare tactics

Posted on October 26, 2007 by Brian Webster
Filed Under Apple | Leave a Comment

I just read this article on MacJournals regarding MacFixit’s tendancy to overhype problems, and I’m glad someone is calling a spade a spade here. MacFixIt used to be a useful site, but in recent years it has gone downhill in the quality of what they publish, almost to the point of being useless, or worse, harmful. It reminds me somewhat of Symantec trying to hype nonexistent virus threats to the Mac so they can sell more copies of Norton AntiVirus that nobody needs.

The article uses a recent MacFixIt post on DiskWarrior as an example, and I actually used to work for Alsoft for a few years, and it’s definitely not the first time this sort of thing has happened with MacFixIt. We had to deal with them on several occasions when they posted various stories, mostly regarding DiskWarrior, that either stretched the truth or were just outright false.

It seems that a large amount of MacFixIt’s material comes from reader e-mails and other such input. That’s not a problem in and of itself, but the problem is that there is almost no effort put forth on their part to filter and/or verify the statements made by their readers. The result is that stories go up on the site that have absolutely no basis in reality, simply because one or two readers e-mailed in. “I noticed that when I upgraded my iLife on the full moon, it crashed my machine, but then when I rebooted and tried again when the moon was waning, it worked!” results in the headline “Warning: iLife installer deletes your photos when installed under a full moon!“

MacFixIt seems to hardly ever even bother to try some of these things readers write in about to see if they actually behave as described, but even worse, they often won’t even try verifying something with the developer of an application if a problem is reported with it. This happened several times at Alsoft, where some reader reported a problem with DiskWarrior and blamed it on something, and MacFixIt happily plastered it on their front page as though it were gospel, causing all sorts of people to panic about running DiskWarrior under whatever circumstances they claimed caused the problem. I remember one case in particular where they claimed that DiskWarrior wouldn’t work with Firewire 800 drives (which is utter nonsense), simply because some reader had had a problem rebuilding their own Firewire 800 drive. Of course it turned out to have a completely different cause (a bug in Quicktime), one that had actually already been well documented months ago, on MacFixIt’s own site!.

Had they bothered to simply shoot an e-mail or phone call our way, we could have provided them with the solution, they could have referred their reader to their old article with the solution, and saved everyone a whole lot of hassle. This is not only a problem for MacFixIt’s readers, but it costs the victim company time and money in responding to the resulting support calls and e-mails, plus the effort needed by the company to try to set the record straight.

So, if you’re a regular MacFixIt reader, I would encourage you to take everything they say at least with a grain of salt, if not to stop reading the site altogether. They have journalistic integrity on par with the National Enquirer. And if you do experience a problem with a program, contact the program’s developer. They are often quite helpful and actually know what they’re talking about, and will be happy to help you with your problem. Now if you’ll excuse me, I need to go install Leopard before the tides come in…

iPLM Leopard update

Posted on October 24, 2007 by Brian Webster
Filed Under News, iPhoto Library Manager | 4 Comments

Just a quick note on iPhoto Library Manager compatibility with Leopard:

That’s all for now, I’ll try to keep updates coming as I know more.

Apple totally stole my line!

Posted on October 17, 2007 by Brian Webster
Filed Under Apple | 3 Comments

I was looking through the Mac OS X Server section of Apple’s website, which has also been updated with Leopard info in the last couple days, when I saw this:

Apple - Mac OS X Server - Features - File Sharing-1.jpg

Hmmmm, this is seeming awfully familiar… where might I have seen this before?

Fat Cat Software - iPhoto Library Manager.jpg

Yeah, OK, my evidence is a little slim…. so far. But I’ve got my eye on you, Apple!

Top 10 obscure new Leopard features

Posted on October 16, 2007 by Brian Webster
Filed Under Apple | 1 Comment

I was just reading through the 300 new Leopard features just posted today on Apple’s site. They usually have a list like this with each major OS X release, and I always find it interesting, as there are usually a few little features that don’t make the “top features” list, but are the kind of refinements that can make upgrading worthwhile. Here are a few that I found that I’m looking forward to using.

  1. Scriptable System Preferences: There’s all sorts of functionality in System Preferences that I wish again and again I could change using a script. It doesn’t look like everything is scriptable, but it’s definitely a step in the right direction
  2. UI Recording and Playback: Back in the day, Applescript used to support recording, which was a great way to set up simple tasks and learn scripting. This has fallen by the wayside in OS X, but I’m glad to see some kind of recordability make it back into the OS, even if it’s slightly less sophisticated.
  3. Spring-Loaded Dock: I knew about this before, but apparently in addition to opening folders via the dock, you can also “spring-load” applications. Pressing the space bar while holding a drag over an app in the dock will launch the application. I’m pretty sure I’ll find ways to use this.
  4. Finder Path Bar: This is a nice little touch that puts the full path to the current folder in the bottom bar of your Finder window, similar to the one you see when selecting a search result. Simple, but will definitely make life easier.
  5. Inline iCal Editing: I never really liked having to shuttle all the way over to a separate window/drawer to edit iCal events. This looks like it will be much more intuitive.
  6. iChat Audio/Video Recording: I don’t do audio/video chats that often, but I love having transcripts of my text chats to look back at, and being able to do this with audio/video chats is definitely nice to have.
  7. Self-Tuning TCP: One of those under-the-hood optimizations that probably should have been done a while ago, and for which there are multiple third-party ways to enable it. Nice to see this here.
  8. PDF Manipulation in Preview: This is sweet, being able to reorder pages in a PDF, or copy pages from one PDF to another. You can combine multiple PDFs into on or split them apart. Preview is really getting to be a pretty powerful little application.
  9. Calculations in Spotlight: Finally, I can do quick calculations directly from my keyboard without having to open a separate app or widget.
  10. Scroll Non-Active Windows: Another little feature that I’ve found myself wanting fairly often. I sometimes employ the command-drag trick to drag a background window’s scroll bar, but just being able to crank the scroll wheel is much nicer.

iPhoto Library Manager and Leopard

Posted on October 12, 2007 by Brian Webster
Filed Under Development, iPhoto Library Manager | 1 Comment

I just thought I would drop a quick note regarding plans for Leopard compatibility for iPhoto Library Manager. The short version is that iPhoto Library Manager will support Leopard fully by the time Leopard comes out. Yay! Since things can change and break things at the last minute with new OS releases, I won’t actually be releasing a Leopard compatible version of iPLM until I can actually test it with the final version of Leopard, but I’ve got the big stuff figured out already. For those interested in the nerdy technical details, read onward.

Leopard will require some changes in the way iPhoto Library Manager works under the hood. iPLM uses the Input Manager mechanism of Mac OS X to load a bundle of code into iPhoto which supplements iPhoto’s Applescripting capabilities, which is what makes features such as copying albums and merging libraries possible. Some other programs, such as Inquisitor and 1Passwd also use input managers to implement their functionality. However, as has been reported by Ars Technica and discussed on some other blogs, input managers are no longer going to be supported under Leopard.

Other developers have found other methods to do what they need to do under Leopard, such as 1Passwd, whose developers say they are going to switch to a WebKit plugin, which works well for them since their product is web browser oriented. iPhoto Library Manager is going to take a different approach though.

One difference between iPLM and some other apps that use input managers is that iPLM only actually needs its code to be loaded when it’s actively doing something with iPhoto, like copying some albums between libraries. It doesn’t matter if the code is loaded every time iPhoto is launched, unlike say, Inquisitor, which pretty much always has to be there to be of any use.

So, instead of a plugin based approach, under Leopard iPLM will use a handy little feature of the OS X dynamic linker, the DYLD_INSERT_LIBRARIES environment variable. Basically what this does is allow you to load additional dynamic libraries in an application (and even substitute for libraries the application is already linked to). The most well known usage for this feature is the MallocDebug developer application, which loads a custom debug version of the malloc library that replaces the normal system library and provides all sort of information on memory usage in the application being debugged.

The downside to this approach is that it requires relaunching the application in question in order to load the additional code, since you have to set up this environment variable and then launch the application yourself. So, for something like Inquisitor, launching Safari directly from the dock would not load the code automatically. There would have to be a separate program that performs the special setup and launch Safari itself, which would be a pain in the butt for users. However, this isn’t really a problem for iPLM, since it has to relaunch iPhoto multiple times during an album copy anyway, so having to do the special setup doesn’t really change the flow of things at all.

There are a couple other upsides to this approach:

The only feature that will be lost as a result of the change is putting the name of the current library in the title bar of the iPhoto window itself. This was a neat addition that I put in on a whim, but since the iPLM code will no longer always be running in iPhoto, this will be going away.

In retrospect, if I had known about this method of doing things back when I first wrote iPLM 3.0, I probably would have done it this way in the first place, since it’s less intrusive and uses a long standing feature of dyld that isn’t likely to go anywhere anytime soon. Like I said above, this method isn’t feasible for many programs that are currently using input managers, but this may still prove a useful technique to some other programs transitioning over to Leopard.

iPhoto 7 editing behavior

Posted on October 9, 2007 by Brian Webster
Filed Under iPhoto, Tips & Tricks, iPhoto Library Manager | 1 Comment

While fiddling around with the editing controls in iPhoto 7, I came across a small bit of new behavior that I thought may be interesting to some. If you use any of the sliders in the “Adjust” palette, iPhoto 7 will actually remember the positions of those sliders if you come back to that photo to edit it a second time.

Adjust.jpg

Picture after editing and reopening

This is in contrast to iPhoto 6, where opening this photo back up again would result in the “Temperature” slider being reset to 0. This is pretty cool overall, even if it prevents you from doing X-TREME 200% SHARPNESS adjustments by sliding the slider to 100% twice.

However, if you choose to edit your photo with an external editor, such as Photoshop or Preview, iPhoto will not remember these slider settings.

Adjust-1.jpg

Picture after editing in Preview

Also note that when copying photos with iPhoto Library Manager, transferring both the original and modified versions of the photo does the equivalent of editing in an external editor, so the slider settings won’t be transferred.

iPhoto 7.1 update

Posted on September 27, 2007 by Brian Webster
Filed Under News, Updates, iPhoto Library Manager | Leave a Comment

Naturally, since I released an update to iPhoto Library Manager yesterday morning, Apple had to go and release an update to iPhoto about 5 hours later that broke some stuff. Worst. Timing. Ever.

A few things needed tweaking to maintain compatibility, but it wasn’t much, and I’ve posted a new update to iPhoto Library Manager (now version 3.3.2) to get everything working properly with iPhoto 7.1 You can download the new version from the main iPLM page.

iPhoto Library Manager 3.3.1 released

Posted on September 26, 2007 by Brian Webster
Filed Under News, Updates, iPhoto Library Manager | 1 Comment

iPhoto Library Manager 3.3.1 is now available for download, incorporating several bug fixes and a couple of new iPhoto 7 specific features. The new version is a free update for existing iPLM users, you can just download the new version and replace your old one with it. There were a couple common problems that people were running into with iPhoto 7, which should be alleviated somewhat with this new release.

iPhoto 7 seems to be a little flakier that previous versions when it comes to properly updating thumbnails for photos that have been edited. The thumbnail would end up reflecting the original version of the photo instead of the modified version, making it appear that the modified photos had not been copied over at all. I’d seen this happen on occasion with iPhoto 6, but it seemed to be become much more common once people started upgrading to iPhoto 7, and this update should hopefully prevent this from happening anymore.

iPhoto 7 adds the new ability to hide selected photos in your library, to help you be able to navigate your library and ignore photos you don’t need to work with at the moment. iPhoto does have an item in its View menu that will let you show/hide the photos you have marked as hidden, so you can still reveal them if you need to, then easily hide them again. However, iPhoto does not write out information for hidden photos to its AlbumData.xml file, which is what iPLM reads to display the library’s album list in its window, and is also used by iMovie, iDVD, Pages, and many other applications to let the user easily use their iPhoto photos in those applications. This behavior occurs even if you have elected to display your hidden photos in iPhoto’s interface, so there is no way to access hidden photos from other applications.

I actually filed a bug with Apple on this issue. The good news is I got a quick response, but the bad news was the response was “Behaves Correctly”. Grrrr. The explanation:

“The View > Hidden Photos option is to allow users to manage their hidden photos (photos marked hidden) without inadvertently making them available to other applications.”

So this means that if you want to access photos from another application that you’ve marked as hidden, you need to actually unhide those photos, go do your thing with them, then come back to iPhoto and mark the photos as hidden again. Of course this means that you get to be the one to keep track of exactly what photos those were, then go find them again in iPhoto to re-hide them. Needless to say, I think this is exceedingly silly, especially since the View > Hidden Photos option would allow you do exactly the same thing with much less hassle. I’d encourage anyone who’d like to see this behavior changed to provide feedback to Apple, either via bug report or the iPhoto feedback page. And as always, be polite. :-)

But, the good news is that hidden photos are still accessible via Applescript, so iPLM 3.3.1 adds an option that will copy hidden photos, and also re-hide them in the destination library after they’ve been copied over. There are some other goodies in the new version, and you can find the full list of changes on the release notes page.

Subclassing NSSortDescriptor for fun and profit

Posted on September 7, 2007 by Brian Webster
Filed Under Cocoa, Programming, Development | Leave a Comment

In the project I’m currently working on, I’m using a pretty standard NSTableView + NSArrayController setup using the default sorting functionality. However, I found myself wanting to do some custom sorting, i.e. not just the usual sorting provided by @selector(compare:). This is made a little more complex by the fact that the columns of the table can be dynamically added and removed, so it’s not quite as simple as just changing the sort selector in Interface Builder. On top of that, I later found that I needed more customization still, because I needed to do special handling of nil values that was different from NSSortDescriptor’s behavior.

So, I set off to make a custom subclass of NSSortDescriptor. I can just override compareObject:toObject:, easy as pie! Right? Er… not quite. There really isn’t any information at all in the Cocoa docs about subclassing NSSortDescriptor, and there are a few gotchas that aren’t necessarily obvious when implementing the subclass, especially if you’re using it with an NSTableView.

To begin, I made my subclass (ITSortDescriptor) and overrode the compareObject:toObject: method. This worked fine to begin with, but I discovered that if I clicked on a table column to change the sort order of the table, it would soon revert to the default sort behavior. After some debugging, I discovered that the reason for this was that NSTableView was making copies of the columns’ sort descriptors using the NSCopying protocol. NSSortDescriptor implements NSCopying, but apparently its implementation will always return an instance of NSSortDescriptor, even the object being copied is an NSSortDescriptor subclass. So, I implemented copyWithZone: in ITSortDescriptor to return an instance of the subclass rather than a plain NSSortDescriptor. The implementation is pretty straightforward:

- (id)copyWithZone:(NSZone*)zone
{
return [[ITSortDescriptor alloc] initWithKey:[self key] ascending:[self ascending] selector:[self selector]];
}

This solved the problem for some cases, but there were still times when the column would revert to its old sorting behavior. I narrowed it down to when the table was already sorted by the column in question, and then you clicked on that column again to reverse the sort order. Apparently, NSSortDescriptor’s implementation of reversedSortDescriptor suffers from the same problem as its implementation of copyWithZone:. Overriding that in a similar manner then fixed that problem:

- (id)reversedSortDescriptor
{
return [[[ITSortDescriptor alloc] initWithKey:[self key] ascending:![self ascending] selector:[self selector]] autorelease];
}

To be really cool, instead of having [ITSortDescriptor alloc], that could instead be [[self class] alloc], but that would only really be useful if that’s what NSSortDescriptor did itself.

So with those modifications, I now have my table sorting just the way I want it. I thought I’d blog this so that anyone else who came across this stuff and was banging their heads against the wall might find it and save themselves some pain.

In the Spotlight

Posted on August 29, 2007 by Brian Webster
Filed Under News | 3 Comments

Not OS X’s Spotlight, this time at least. No, I’m actually being featured in the MacTech Spotlight in this month’s issue of MacTech magazine! It’s a monthly feature they do where they do a Q & A with a different Mac developer each month. So, if you pick up a September copy of MacTech and flip to the back, you’ll get to see my ugly mug along with paragraph after paragraph of my infinite wisdom*. I’m sure I’ll be getting the call to go on Letterman any day now…

*actual size of wisdom will vary, some restrictions may apply, void where prohibited

« go back — keep looking »

Feed