Users of Quicken 2005, 2006, and 2007 who read sites like TidBITS almost certainly know already that Intuit’s financial-tracking software was never properly updated for Intel-based Macs, and will not function under Mac OS X Lion. For as long as Intel-based Macs have been on the market, Quicken has run under the sufferance of the Rosetta emulator, which allows old PowerPC-based software to keep on trucking. As far as anyone can tell at this point, Rosetta will not be available for Lion. (See “Rosetta and Lion: Get Over It?,” 23 May 2011.)

However, not every Quicken user will be as up to speed as you and I. That’s why I, as a registered Quicken owner, was pleased to receive email from Intuit reminding me of, and clarifying the situation with, Lion compatibility issues. While the under-featured Quicken Essentials is ready for Lion, the 2005 through 2007 versions will not work in Lion. There have been rumors that Intuit and Apple might be working together to create a hybrid Rosetta/Quicken monster to enable the software to keep running, but for now, those remain rumors.

Potentially more important, Intuit also noted that Lion users will not be able to import data into Quicken Essentials from Quicken 2005, 2006, and 2007, due to the converters requiring Rosetta as well. That’s simply ridiculous, I have to say. There’s no excuse for Intuit’s inability to update a converter for Lion, a fraction of the work required to fix an app.

What I found most interesting about Intuit’s email message, which links to this longer support document about Quicken and Lion, is that Intuit now openly acknowledges the problems that have kept Quicken Essentials from being a legitimate replacement for previous versions:

This option [using Quicken Essentials] is ideal if you do not track investment transactions and history, use online bill pay or rely on specific reports that might not be present in Quicken Essentials for Mac.

Precisely.

In the fabled Good Old Days, figuring out how long it would take to get your hands on the discs containing the latest Mac OS X upgrade involved either determining how long it would take you to drive to the nearest retail outlet selling the package, or monitoring a delivery tracking page in your Web browser to see where the shipment you ordered containing the discs currently was on its journey to your eagerly awaiting Mac.

In these Good New Days, however, the latest upgrade to Mac OS X 10.7 Lion will be available only from the Mac App Store, which means you can get your hands on it instantly — where “instantly” means as fast as your Internet connection to Apple’s servers can download it.

For most of us, “instantly” will still mean a considerable wait, so you probably don’t want to purchase Lion if you have to walk out the door with your laptop a few minutes later. But how long will you have to wait as the rough beast slouches its way onto your hard disk? It’s not hard to come up with a reasonable estimate.

First, you need to find out how much throughput you get from your Internet connection — not how much throughput your service provider says you get, but how much you actually get, which may vary with time of day. (Early evening is often the worst time for residential Internet connections, as everyone heads to Netflix to stream videos.) Fortunately, there are a number of Web sites that can test your connection, such as Speedtest.net. You can run a quick test on that site (it only takes thirty seconds or so) to find out the throughput of your connection in Mbps (megabits per second).

Once you know that, you need to know how big the download is. Fortunately, that is not a big secret: the Mac OS X 10.7 Lion installer is known to be 3.76 GB. With that information, you can whip out a number 2 pencil and a pad of paper and do some quick ciphering — or you can go to another site that will do it for you, such as Derek Tsang’s Download Time Calculator. Simply plug in the size of the download, and the throughput of your connection, and hit the Get Download Time button. You’ll get a reasonable approximation of how long it will take for the Lion installer to make it onto your Mac. (For a sense of how long the download would take on various standard Internet connections,
check out the Gaijin Download Time Calculator.)

Of course, the estimate you get is only provisional: The download speed also depends on the throughput of the Mac App Store servers and Internet connections, along with the route between you and the Mac App Store. As we all know, those variables can vary. But at least you’ll know the least amount of time it might take, and be able to plan your day accordingly.

When iMovie for iOS 1.2 was announced earlier this year, I was told by an Apple representative that iMovie ’11 would be able to import movies created in iMovie for iOS, the app that runs on the iPad, iPhone, or iPod touch. However, that information turned out to be incorrect: GarageBand was able to import projects created in GarageBand for iOS, but the same was not true of iMovie. (See “New iOS Versions of iMovie and GarageBand,” 2 March 2011.)

It turns out the Apple rep wasn’t wrong, just premature. Today’s release of iMovie 9.0.4 brings the capability to import projects created in the iOS app into the Mac app. That means you can start a project on your iOS device (when the video or your ideas are still fresh, or you just need to kill some time) and bring it into iMovie ’11 for finishing.

In a quick test, I assembled a movie on my iPad 2 and then imported it into iMovie ’11. All the elements in my movie (including background music, sound effects, Ken Burns Effect settings, and themes) came across fine. In fact, iMovie ’11 recognizes that my project used the Neon theme, which is available only in the iOS version, and includes other theme elements not used in the project, such as alternate title styles. Changing the project’s theme to one of the iMovie ’11 themes removes the capability to go back to the iOS theme, however.

Unfortunately, the process of getting a project out of iMovie for iOS and into iMovie ’11 is still as cumbersome as ever. (I’d love to see the capability to sync projects via iCloud the way we’ll be able to sync documents, but I’m guessing the large size of iMovie projects would make the feature difficult to work with.) The steps go like this, if you want a handy reference:

1. In iMovie for iOS, tap the Share button.

2. Tap the Send Project to iTunes button.




3. Connect your iOS device to your Mac.

4. In iTunes, select your device in the sidebar and click the Apps button at the top of the window.

5. Scroll down to the Apps list, select iMovie, and select the project you shared.




6. Click the Save To button and choose a destination for the project file, or simply drag the file from the iMovie Documents list to a window in the Finder.

7. In iMovie ’11, choose the new File > Import > iMovie for iOS Project item and choose the project file you saved. Specify whether to add the project’s footage to an existing iMovie Event, or to create a new Event.

8. Click the Import button to convert the project and bring it into iMovie ’11.

Alas, it’s not possible to make edits in iMovie ’11 and ship them back to iMovie for iOS for later editing on the road. Perhaps in a future update.

In addition to being able to import iMovie for iOS projects, iMovie 9.0.4 fixes issues where some audio adjustments didn’t stick, improves performance when working with large quantities of video clips with keywords and with large iPhoto libraries, and adds support for full screen mode in Lion.

The iMovie 9.0.4 update is a 76.2 MB download, available via Software Update, as a direct download, or as an update in the Mac App Store if you purchased the application there.

With each of the MacTech Boot Camps in San Francisco, Dallas, and Boston selling out, Mac consultants and support techs in Los Angeles and Chicago can now look forward to events in their cities. And if you’re a bit further away, the MacTech Boot Camp Los Angeles on 27 July 2011 takes place at the Sheraton Gateway near LAX (Los Angeles International Airport), making it easy to fly in for the day. MacTech Boot Camp Chicago is a month later, on 31 August 2011, at the Hotel Allegro in downtown Chicago.

MacTech Boot Camp is a single-track, hotel-based seminar designed to serve the needs of consultants and techs, with high-quality technical and business content from experts combined with opportunities for networking with other consultants and vendors. Speakers for the Los Angeles event include Ben Levy, Phil Goodman, Ric Wilson, Sean Colins, Chris Keller, Jonathan Goldhill, and Peter Linde.

MacTech Boot Camp normally costs $495, and although early-bird pricing has expired for the Los Angeles event, TidBITS readers can still take advantage of the $200 discount thanks to our media sponsor status, dropping the price to $295. The TidBITS-specific pricing also applies to the Chicago event. Since all the events so far have sold out, it’s best not to wait too long to register.

After Apple’s recent confirmation of the worst fears of iWeb users – that the hosting of iWeb sites as part of MobileMe will disappear on 30 June 2012 (see “Apple Details Transition from MobileMe to iCloud,” 24 June 2011), many readers of my “Take Control of iWeb ’09” ebook contacted me to find out where they should move their sites. There are a couple of options, depending on how serious your site is, and whether or not you have a custom domain.

Sites with Custom Domains — For anyone with a unique (non-MobileMe) domain name or with a high-traffic Web site, my recommendation is to bite the bullet and sign up for a paid Web hosting account with a known hosting provider. The Web hosting provider you select is up to you, but some of the better-known hosts include DreamHost, Bluehost, HostGator, and GoDaddy. Prices start around $5 per month.

Once your new host has provided you with login information, launch iWeb and select your Web site in the sidebar to reveal the Site Publishing Settings for that site. You’ll need to enter the site name, your contact email address, and information (server address, user name, password, and initial path) for the FTP server associated with your site.

Provide the site URL (which is used to set up links and RSS feeds) and decide whether or not you’d like to update your Facebook account each time you publish your site, and click Test Connection to make sure that all of your settings are correct. If they are, you’re ready to publish your iWeb site to the new host with a click of the Publish Site button.

You’ll also need to repoint your custom domain appropriately; contact tech support at your new hosting company if you need help doing that.

Sites in the MobileMe Domain — If you’ve been happy with a MobileMe URL like http://web.me.com/stevensande and don’t have significant traffic to your site, then a free hosting solution is probably all you need. The easiest is cloud storage provider Dropbox, which offers free 2 GB accounts that provide plenty of storage space for all but the largest iWeb sites. Follow along for a short tutorial on how to set up Dropbox and iWeb to host your iWeb sites.

One caveat: Although the suggestion for Web site hosting comes directly from the Dropbox wiki, the service is not intended for “production” Web hosting. A few personal pages or a testing site shouldn’t cause you any grief, but Dropbox does reserve the right to turn off your public links if the system detects unusual levels of bandwidth consumption.

1. To begin with, you must have a Dropbox account. If you don’t have one, go to Dropbox’s home page and download the Dropbox software, install it, and set up your account. I also suggest watching the video on the Dropbox home page to understand the concept behind the application and service.

   (In essence, Dropbox mirrors the contents of the Dropbox folder in your home folder to the Dropbox servers, and syncs all changes to files in that folder up to Dropbox’s servers, and then down to all your other devices. If you share a folder with other people, their copies of documents in that shared folder are synchronized on every save as well.)

2. Once you’ve installed the Dropbox software and have familiarized yourself with it, you’re ready to roll. In the Finder, open your Dropbox folder and notice that Dropbox has created some folders for you, including Public. Open Public and create a new folder inside it to hold your site. You can name it anything you want. For this example, I named mine “web”.

3. Open iWeb and select your Web site in the sidebar to reveal the Site Publishing Settings.




4. Choose Local Folder from the Publish To pop-up menu.

5. Enter the name for your site and your contact email address, and then click Choose Folder Location.

6. Navigate to the folder that you created in Step 2, then click Choose:




7. For now, that’s it. If your Web site is ready to publish, click the Publish Site button at the bottom of the iWeb window. This will publish the site files to the ~/Dropbox/Public/web folder. Within a few seconds or minutes, depending on your connection speed and the size of your site, those files are synced to your Dropbox account “in the cloud.”

8. Back in the Finder, navigate to the ~/Dropbox/Public/web folder, and inside it you’ll see an index.html file. Control-click that file and from the hierarchical Dropbox menu in the pop-up menu that appears, choose Copy Public Link to put the link in the Clipboard. That’s the URL at which your Web site can be reached, and you can send it to friends or clients to show them the site.




9. One more step! To make sure all your links work properly, go back to the Site Publishing Settings in iWeb for your site. See that big, empty space where it says Website URL? Paste the URL that you copied in Step 8 into that field and then delete the index.html at the end of the URL. That address is the root URL for your new site. Click Publish Site again to republish your site, then go admire your handiwork by pasting the previously copied link into your Web browser.

While I didn’t have time to check all of the widgets and features that are part of iWeb ’09, all of those I was using on my sample site, including Countdown Timer and HTML Snippets, worked perfectly when served via Dropbox. Any feature that uses a server-side capability specific to MobileMe will not work, so be sure to test your site functionality on Dropbox before sending out the URL.

[Steve Sande is Features Editor for The Unofficial Apple Weblog (TUAW.com) and the author of “Take Control of iWeb ’09.” His other titles include “Taking Your iPad 2 to the Max,” “Taking Your iPhone 4 to the Max,” and the upcoming “Taking Your Mac OS X Lion to the Max,” all from Apress.]

It’s unlikely that we’ll see a Mac OS X 10.6.9, given the nearness of Mac OS X 10.7 Lion’s release, but if Apple were to release 10.6.9, I would be forced to recommend that TidBITS readers not install it immediately. After all, both 10.6.7 and 10.6.8 introduced entirely new problems that affected large numbers of people while resolving extremely specific bugs that likely affected only a small set of the user base.

That’s unlike Apple. Although there have been exceptions, Mac OS X releases have, for the most part, been either positive steps forward or at least neutral. As a result, I’ve had little reason to recommend extreme caution when upgrading. Early upgrades — the 10.x.1 and 10.x.2 releases — generally address common bugs and problems and are thus worth getting quickly. And later upgrades — those that come after 10.x.5 — are largely aimed at mopping up highly particular problems and lurking infelicities, and seldom introduce new problems.

So what explains the font problems in 10.6.7 that forced the Snow Leopard Font Update (see “Apple Releases Snow Leopard Font Update,” 26 April 2011), or the printing problems in 10.6.8 that are currently best addressed by replacing four Unix applications with their previous versions (see “Mac OS X 10.6.8 Suffers Printing and Audio Problems,” 1 July 2011)? Are Apple’s testers just getting sloppy? Are they too focused on testing Lion to give sufficient attention to Snow Leopard? What about developers? Perhaps they too have been more focused on developer previews of 10.7 than on new versions of 10.6?

Or maybe this is part of the price of success? What if these problems are directly related to the ever-increasing popularity of the Mac and the concomitant growth of the surrounding industry of software and hardware manufacturers? And, of course, to Apple maintaining this growth over the last 10+ years, which has given us not just multiple generations of software and hardware, but an expanding number of professional users who rely on their Macs for day-to-day work.

In short, perhaps the entire Mac ecosystem has grown so large that it has exceeded Apple’s internal ability to test sufficiently against the myriad real-world configurations that have sprung from each and every Macintosh purchase. And, I would argue, even if Apple doesn’t target the Mac at the enterprise market, the consequences of introduced bugs have more of an impact on professionals than ever before, simply due to the increased number of people relying on the Mac for their livelihoods.

What then is the solution? Certainly, Apple could just employ more testers and move more cautiously with Mac OS X releases. Or we users could attempt to hold developers responsible for better testing — it’s somewhat troubling that both Parallels and PGP failed to discover and address (either in code or with communication) their conflicts with 10.6.8 before it shipped.

But neither of these solutions is satisfying. Apple can’t possibly test every conceivable user configuration, nor would we want the company to delay necessary fixes for obsessive testing. And yes, it would be nice if developers did a better job of testing too, but all developers have limited resources to devote to the task.

I propose a more modern, democratic solution: public betas of interim Mac OS X releases, starting with 10.7.1. As much as I know the very concept goes against Apple’s secretive, controlling grain, I think the company should consider it.

[Update: In fact, as I’ve learned from some of the comments on this article, Apple actually has a program somewhat along these lines. Called AppleSeed, it’s an invitation-only program that enables everyday users to test pre-release versions of Apple software and provide Apple with feedback. From what I can tell (and what I read in this recent Ars Technica article) it’s almost entirely secret, though, so it’s unclear how it compares with what I suggest below, and the simple fact of the matter is that, just like Apple’s internal testing and developer testing, it
failed to bring the problems that plagued 10.6.7 and 10.6.8 to the forefront.]

Of course, I’d hope Apple would do a better job than many other companies that do public betas. For instance:

• The option to get public betas should be something that the user sets in Software Update, so participating in a public beta doesn’t require users to waste time manually downloading and installing. This is just respect for your testers — let them focus their time on actual testing, rather than fussing with manual installations.

• For those who install the public betas, there should be an option to revert to the previous installed version, and to the current shipping version. That way, if a user installs a public beta and discovers a bug that prevents everyday usage, she can revert easily to a functional version of the operating system. Again, such a feature acknowledges that testers are donating their time, and if a beta is harming their ability to earn a living, it should be easy to return a Mac to a functional state.

  (In fact, now that I think of it, Software Update should work with Time Machine to create a snapshot of the operating system before installing an update for all users, so if a user experiences problems, reverting is merely a matter of clicking a button in Software Update. Although I’ve not seen this personally, my understanding is that Windows has long had a feature like this. In an involved Twitter conversation, TidBITS friend Andrew Laurence suggested that this is actually the key thing for Apple to work on, since he felt a public beta program wouldn’t serve Apple’s interests, whereas the capability to revert from a troublesome update would
  help everyone.)

• Once a public beta is installed, a Submit Bug Report item should appear in the Apple menu. Choosing it should display a form that helps users make useful reports; it could even be an assistant that walks the user through several screens, collecting information about the problem in each one. Those bug reports, along with automatically collected logs, should go directly into Apple’s internal bug report database. Currently, the only way to report bugs is via Bug Reporter, a clumsy Web-based system that feels as though it hasn’t been updated in at least 5 years.

• I don’t have a suggestion of how this could best be done (iTunes gift cards? Hardware discounts?) but Apple should reward users who consistently submit helpful and accurate bug reports. It’s a small thing, but when a large company like Apple acknowledges individual assistance, as in the credit for reporting security vulnerabilities, it goes a long way.

• One final thought. Especially now that Apple IDs are required to purchase Mac OS X Lion, Apple could open up a private discussion forum for those participating in the public beta program, which would enable people to figure out whether any problems they were seeing were more widespread. I have no idea if Apple’s discussion software would support this, but it would be extremely cool to give users a rating based on how many good bugs they’d reported.

Again, the very concept of allowing users to see betas of Mac OS X goes against Apple’s desire to control the message, but as far as I can tell, Apple isn’t enforcing its developer non-disclosure agreements at all — many Web sites are now publishing NDA-covered information about Lion with impunity. So perhaps Apple doesn’t care about technical details leaking out, and with small updates like 10.7.1, it’s not as though there would be any damage to Apple’s competitive position if someone were to discover that a particular bug has been fixed or some other problem has been introduced.

And, on the plus side, releasing public betas could significantly improve customer confidence in Apple’s ability to provide a solid operating system. It takes a long time to win trust that can be lost nearly instantly, and the last two releases of Snow Leopard have distinctly hurt Apple’s reputation.

The Thursday presentations at the Computers, Freedom, and Privacy 2011 conference were anchored by a keynote speech by Senator Pat Leahy, a Democrat from Vermont. This is the second time I’ve heard Leahy speak in three weeks, the first time being at a fancy lunch sponsored by NetCaucus.org.

Leahy, by many accounts, is a smart cookie and a strong advocate for privacy rights. He received a glowing affirmation onstage from Marc Rotenberg, Executive Director of the Electronic Privacy Information Center; I’ve known Marc for nearly twenty years, and consider him to be an extremely effective organizer and thoughtful commentator on privacy and Internet issues, so when Marc says something good about someone, I’m inclined to think pretty highly of that person.

And this is why both of Leahy’s speeches were so damn disappointing. Yes, he finally included a few tidbits of useful information, which I’ll get to shortly, but nearly all of it was political pablum: The issues raised at CFP are extremely important. We’re all to be commended for our interest and our work. He needs our help to get his legislation passed.

In Washington, this isn’t just preaching to the choir, this is saying, “Gosh darn it, your robes are immaculate and you all sound terrific.”

CFP is open attendance, and is one of the few places where you can find an audience where not everyone is singing from the same hymnal. There are debates here about the nature of privacy, the tension between commercial profit-making activities and the public good, and incursions against human rights by those who say it’s for the defense of the populace. Speakers and attendees are on both sides of each of these issues; what we share in common, by and large, is a deep understanding of the technical and social forces at work, and a commitment to our particular sides of the fence.

So why did Leahy stand up and give such a weak presentation? It would have been appropriate on CSPAN or Rachel Maddow, where he’s not addressing an expert community. But here, I don’t want to hear that we’re important and he needs our help; I want to hear his expert insights on the legislative process, the reason why past efforts have failed, and the specific methods by which people can get involved on one side or the other of an issue. If he needs our help, I want to hear how.

It’s a missed opportunity, but it’s also more than that — there was no expectation from the audience that a sitting senator would address us about his work and expertise, even though that’s the model used by literally every other speaker at this conference. We would be surprised to be included in the debate at his level; he won’t say anything that could be turned into a sound bite to be used against him. The U.S. Senate, everyone seems to be agreed, is a giant black box — money and votes pour in, a secret alchemical process takes place (known only to lobbyists carrying six-figure paychecks), and the result is U.S. law.

On the same day that a strong progressive voice resigned because he sent inadvisable pictures of himself on Twitter, this is further demonstration that we’re not really engaging in self-government so much as performance art.

All of that said: Leahy spoke of his efforts to pass an update to the Electronic Communications and Privacy Act, which was last passed in 1986. Times have changed. Key points in the new ECPA include the need to get search warrants before government agencies can access sensitive computer data, such as location tracking or cloud storage; such information is currently unprotected and can be handed over based on the decisions of the host companies. He is also working on setting a federal standard for notifications in the event of a security breach at a private company, so people who have had their data stolen will be told about it; again, this is currently done on an ad-hoc basis by the companies in question.

This is the fourth time Leahy has introduced the latter legislation, and he said he hopes that the fourth time is the charm. It seems to me that had he spent more time discussing the meat and potatoes of his two bills, the obstacles he’s facing, and the specific initiatives he’d like to see from the people in the audience — and more importantly, the much larger group of you reading what was said here — then perhaps he wouldn’t have to rely on hope. It should be his job to give us the specifics, so that I can relay them to you, and so you can then go on to promote the legislation you agree with, or oppose the laws you think are dangerous.

But that’s all in the black box. And perhaps I’m asking too much of the man. He’s just a senator, and you and I are merely citizens.

Airfoil 4.5 — Rogue Amoeba continues to extend the wireless reach of audio with Airfoil 4.5, a major update to its popular wireless audio distribution utility. Most notably, Airfoil 4.5 adds full support for third-party AirPlay devices, enabling you to send audio to any AirPlay-enabled speakers or devices. AirPlay support has also worked its way into the free Airfoil Speakers extra, enabling Airfoil Speakers to receive audio from iTunes and iOS apps, along with Radium on Mac OS X. Also new in Airfoil Speakers is the capability to control playback in several new sources like Spotify, Rdio, and Radium. Airfoil 4.5
introduces support for Mac OS X Lion, opts out of ClickToFlash, and provides a number of bug fixes and performance enhancements. ($25 new, free update, 12.6 MB, release notes)

Read/post comments about Airfoil 4.5.

GraphicConverter X 7.3 — Lemkesoft has released GraphicConverter X 7.3, an update to its venerable graphic conversion software. According to the release notes, the new version includes a number of bug fixes and improvements to existing import modules and CoreImage filters, in addition to support for HTC splash screens and AAI/Dune files, plus email support for Outlook 2011. The update also provides compatibility with Mac OS X Lion, making it a must-download for those planning to upgrade to Lion soon. ($38.99 new from
Lemkesoft’s Web site or the Mac App Store, free update, 100 MB)

Read/post comments about GraphicConverter X 7.3.

KeyCue 5.3 — Ergonis Software has released KeyCue 5.3, an update to its app designed to remind you of keyboard shortcuts whenever you need a hint. The new version features a number of performance improvements and provides better compatibility with several apps, including Screen Sharing, iKey, iChat, and the development environment Eclipse. In addition, KeyCue now includes an optional legend that explains the meaning of symbols used in the shortcut table. (€19.99 new, free update, 6.1 MB)

Read/post comments about KeyCue 5.3.

Opera 11.50 — While Safari, Firefox, and Chrome have been getting most of the attention, Opera has been quietly at work on Opera 11.50, which now includes a long list of new features, improvements, and bug fixes. The Web browser’s user interface has received a number of improvements, ranging from a new icon set to better layout. Opera Link, the company’s data-synchronization service, is now capable of storing passwords alongside other browsing data, while Opera Mail includes better support for Gmail’s IMAP service.
Opera’s support for HTML 5 has received a significant boost through the introduction of numerous new features, including the Opera Presto 2.9 rendering engine. (Free, 13.7 MB)

Read/post comments about Opera 11.50.

Postbox 2.5 — Postbox has released version 2.5 of its eponymous email client, which includes a long list of enhancements, starting with numerous improvements to its user interface. These include tweaks to the app’s signature vertical view, its composition window, message view, and even its notification bar. According to the release notes, Postbox 2.5 also adds IMAP support for Yahoo Mail accounts, an inline quick reply feature, a new inline junk-mail notification panel, and support for searching messages by topic via Spotlight. ($19.99 new from Postbox’s Web site or the Mac App Store, free update, 20.4 MB)

Read/post comments about Postbox 2.5.

EagleFiler 1.5.4 — C-Command Software has updated EagleFiler, its document- and data-archiving app, to version 1.5.4 (see “EagleFiler Turns a Finder Folder Into a Snippet Keeper,” 24 February 2010). According to the release notes, EagleFiler 1.5.4 includes a slew of optimizations and bug fixes, in addition to a few new features. The app can now read data in a more efficient way from several RSS readers, including NewsRack and NetNewsWire, and can import bookmarks from a variety of sources, like Safari,
Delicious, Pinboard, and others. EagleFiler 1.5.4 also includes early support for the upcoming Mac OS X Lion, where the app can run in full-screen mode. ($39.99 new from C-Command’s Web site or the Mac App Store, free update, 11.4 MB)

Read/post comments about EagleFiler 1.5.4.