06.30.07
Posted in History, Open Source, Software at 2:07 am by Smokey
A long, long time ago, in a galaxy, er, back in the late 80s and early 90s, WordPerfect was the dominant word processor, ubiquitous (try finding commercial software today available on that many platforms) and powerful. The Mac version was Mac-like, a good citizen, easy to use and uncluttered yet still powerful (in fact, in 2007, the last released version, 3.5, dating to 1995—with a small but not insignificant update to 3.5e in 1997—does everything I’ve ever wanted to do with a word processor, save Unicode, and I’ve wanted to do some above-average things).
If you’ve been using computers since the late 80s or early 90s, or perhaps went to school in the mid/late 90s at an institution with a Novell network, chances are you have a collection of old WordPerfect documents. Fortunately (if you have any need of the data in those documents), some fine folks have created a very good file format translator (libwpd) for WordPerfect documents, which is available stand-alone and is also incorporated into open-source programs such as AbiWord, KWord, NeoOffice, and OpenOffice.org, and commercial products such as Nisus Writer Express. Currently libwpd supports most features of most common WordPerfect file formats, but the big missing piece was images. After all, everyone has some sort of images in their documents: logos in company letterhead, figures in reports or papers, clip art in family newsletters.
Last summer, the file format translator (libwpg) for the WordPerfect image format really took off, thanks to Ariya, but there was still no way to get a WordPerfect document with an image to open in any of those other applications and include the image. So close, but so far away….
This week Fridrich has been working on finally bringing libwpd and libwpg together, so that WordPerfect documents with images can be opened by other applications and retain their images—and the result looks good! Things are still rough, and and some images still won’t be converted properly, but you can see it with your own eyes; a new hope for old WordPerfect documents with images.
Thanks, Fridrich, Ariya, and all the other libwpd and libwpg hackers; this is indeed an exciting day!
Permalink
06.25.07
Posted in Camino, Links at 9:06 pm by Smokey
An eagle-eyed fan of our favorite browser spotted Camino in the BBC’s on-air ads for its website. That’s right, millions of Britons (and others around the world?) seeing Camino on TV! Pinkerton must have died and gone to heaven. 
(It’s actually Camino 1.0—hey, BBC ad folks, be sure to upgrade to 1.5 for your next spots 
—but cool nonetheless. First person to guess how I knew it’s Camino 1.0 and not 1.5 wins a fabulous ardisson.org prize—bragging rights as “mind-reader of the moment.”)
Update: Chris Lawson notes that the BBC has been using Camino in screenshots on the web for a while, but this is still a whole new level of cool.
Camino doesn’t often get a lot of “high-profile” internet press like “that other browser”—we do have a few fans like tech journalist and blogger Om Malik, browser polygamist extraordinaire (and our very own “staff” designer) Jon Hicks, noted purveyor of Mac nerdery John Gruber, and a couple of others I’m forgetting (sorry!) who write about Camino releases regularly—so it’s always nice to see a new fan among the movers-and-shakers of the web world. Today we hear that noted web standards advocate (and more) Molly Holzschlag is also a Camino fan.
It’s a fun Monday.
Permalink
06.20.07
Posted in Camino, Software at 12:49 am by Smokey
WWDC 2007 was last week, and while many are lamenting the untimely demise of Carbon or marvelling over everything old that’s new again, one startling revelation hit me: Camino is now the most popular Mac-only web browser!
In reality, this means little beyond a bit of fun. I seriously doubt Apple will let the mores of Windows influence the Mac version of Safari the way that those mores govern other browsers, so Safari will still be a Mac app through-and-through, and it doesn’t look like Safari will lose the crown of “most popular browser on the Mac” any time soon. Moreover, neither we nor The Omni Group release statistics on number of users (at least not that I can find in a quick bit of searching), so one has to rely on unscientific, non-random-sampling third-party polls like the Mac OS X Hints “Browser Wars” poll (2007, 2006, 2005)1 to “prove” this popularity. Nonetheless, it’s a fun bit of trivia.
This post brought to you by Camino, the third most popular web browser on the Mac, and now the most popular Mac-only web browser.
1 Another fun statistic is the rise in the number of poll participants—either Mac OS X Hints is getting more readers, or we’re getting more Mac users, or both. ↩
Permalink
06.15.07
Posted in Camino at 8:51 pm by Smokey
Everyone knows the command (⌘) key opens pages in new tabs (or windows, depending on your Tabs preferences) when held down while clicking on a link (“cmd-clicking”). But many people aren’t aware that the ⌘ key performs this “open in new” behaviour in many other places in Camino.
As described in the Camino Keyboard Shortcuts documentation, ⌘-clicking on a bookmark in the Bookmark Bar will open that page in a new tab (or winow). Similarly, ⌘-clicking on a tab group in the Bookmark Bar will make those pages all open in new tabs (appending those tabs to any existing tabs) instead of replacing all the existing tabs.
Likewise, holding down the ⌘ key when clicking on a bookmark or tab group in the Bookmarks menu, or a history item in the History menu, will open those pages in a new tab or window. The same holds true for items inside folders in the Bookmark Bar.
New in Camino 1.5 (and a common feature request, even now), is the ability to open pages or search results in a new tab (or window) from the toolbar. Simply hold down ⌘ when pressing return in the search field or location bar, and instead of loading the search results or page in the current tab, the pages will load in new tabs instead. (This also works for the “Search” item in the page context menu, but due to some fun Carbon-Cocoa bugs, you have to hold the ⌘ key down when invoking the context menu as well as when selecting the “Search” item.)
In most cases, holding down the shift (⇧) key while ⌘-clicking will reverse the “Load in background” Tabs preference, just like it does for links you click on web pages.
With judicious use of the ⌘ key, you’ll never have to open something in the same tab again!
Permalink
06.13.07
Posted in Camino at 1:43 am by Smokey
Session restoration (often called “session saving”) is actually one of the major new features in Camino 1.5, but I’ve seen a bit of confusion over it. The plans for the website include some nice explanations and imagery covering the major new features, but those are not ready yet, so until then, hopefully this post will suffice to clear up any confusion.
Camino 1.5 actually includes two different forms of session restoration. The first one is on all of the time and helps you recover from those nasty crashes you sometimes experience with Camino. 
As you browse, the locations of pages you visit in your windows and tabs are recorded in a file in your Camino profile. If Camino quits unexpectedly, you’ll be prompted when you restart Camino and asked if you want to restore the pages that were open when Camino unexpectedly quit. The code in Camino that saves the current pages is smart enough to not record a page that causes a crash when it loads, so in most cases you can restore the pages from the previous session without worrying about crashing again. Most of the time you’ll have all your pages except the one that caused the crash and can continue browsing where you were before being interrupted.
The second form of session restoration in Camino 1.5 is a more traditional form of “session saving” and can optionally be enabled in the preferences. By checking the box for “When Camino starts: ☑ Load the pages that were open before quitting” in the General preferences, you tell Camino to remember all the pages that were open when you quit Camino manually. When this option is enabled, the next time you open Camino, it will automatically load all the pages that were open when you quit, and you’re ready to continue browsing where you were when that Mac OS X security update installation interrupted you. (If the last time Camino quit was an unexpected quit, crash recovery mode takes over and prompts you, as described above.)
What about saving arbitrary sessions (say, a set of pages you use when checking your stocks, or a set of pages you use when working on a certain project)? The most appropriate way to switch between groups of pages related to certain tasks is still to create a tab group for each task and store the tab groups in the Bookmark Bar for easy access. (Even better, the Bookmark Bar is now the default destination when creating new bookmarks, but Camino will remember the last folder or collection you chose and use that as the default the next time. Oops, that’s another tip! Two for the price of one.)
With Camino 1.5, quitting and crashes no longer are major impediments to your browsing; session restoration quickly gets you back to browsing where you left off.
Permalink
Posted in Camino at 12:52 am by Smokey
One of the things that I’ve noticed over time in the forums and occasional random surfing is that there are a number of Camino features—even some we spend an inordinate amount of time perfecting—that people seem not to know about. To address that, I’ve decided to begin an occasional series of tips highlighting some of Camino’s hidden gems. Hopefully these tips will help you enjoy Camino even more and browse more efficiently and productively than before.
Permalink
06.10.07
Posted in Camino at 3:35 pm by Smokey
Ian “froodian” Leue just landed murph’s patch for bug 175651, aka “the CJK bug,” for Camino 1.0.5, Camino 1.5.1, and the branch nightlies (aka Camino 1.6a1pre builds).
This is a banner day for our CJK users; finally they can switch CJK fonts (albeit only from the Advanced sheet) from Camino UI and we’ll tell Gecko the right font to use. I’ve hated this bug since I first got involved in Camino QA in 2004, and I’m very happy to see it gone. It was one of the places where crossing the Cocoa-Carbon boundary was very difficult, but it was an awful user-experience and a major issue for Camino’s adoption in East Asia. Fixing this bug is a big step towards addressing that. (Recent changes on the trunk should finally allow Gecko to understand Cocoa font names, so the existing UI should work fine there, as intended—although the font defaults will now be wrong until Gecko fixes them to be Cocoa font names instead of Carbon ones.)
Thanks to everyone involved in fixing this bug (which was one of the 50 oldest Camino bugs still open).
Permalink
06.05.07
Posted in Camino at 6:12 pm by Smokey
By the time you read this, Camino 1.5 (codenamed ☃) will be out. We hope you enjoy the new version; we’ve put a lot of work into it and are excited to finally unleash it upon the world.
The road to Camino 1.5 began in January 2006, when the first fixes landed on the MOZILLA_1_8_BRANCH, even while we finished work on Camino 1.0. In the ensuing year-and-a-half, Camino contributors fixed nearly 500 “bugs” (problems or new features), and 25 different people contributed patches for this release; two of those fixed over 100 bugs apiece! Those are pretty impressive numbers, I think, for an all-volunteer, all-free-time development team.
In addition, our fantastic volunteer localization team released 13 localizations in sync with the US English build of Camino 1.5. Sadly, this is a few localizations short of the number in Camino 1.0. There are a few more localizations (mostly completely new-to-Camino languages, like Hungarian) underway that we hope to ship in either a “refresh” of the Camino ML build or in Camino 1.5.1, but if your language is missing from Camino 1.5—especially if it’s one of the languages shipped in Camino 1.0, like Chinese—please stop by the localization site and see how you can help.
This year I didn’t stay up all night helping put the finishing touches on things, but Sam and his crack team of designers worked long and late hours to deploy the new website in sync with the release. Thanks to all of you as well!
What’s next? After a bit of rest, we have a few more bits of polish we want to put on the website, on the wiki, and on the new Camino Planet, but development is already underway on Camino 1.6, so you can check out a nightly build and see what we’re cooking.
Enjoy Camino 1.5, and let us know what you think!
Permalink
06.02.07
Posted in Life, Software at 2:29 am by Smokey
WordPress 2.2 came out a few weeks ago, and sometime recently the Fantastico service (offered by my hosting provider to perform auto-installs and upgrades to common web applications) alerted me that 2.2 was available for upgrade. Tonight I took the plunge.
Every other WordPress upgrade (a half-dozen security updates to WordPress 2.0, the 2.0.x to 2.1 upgrade, and a few 2.1.x security updates) all went without a hitch. Not so 2.2. After the upgrade, I noticed the lovely افكار و احلام and every curly quote, ellipsis, and ☃ had been turned into gibberish (and what’s worse, retyping them didn’t fix anything).
It turns out that the database storing all the “information” for this journal thinks that everything is using the old Latin-1 (Western European) character set for determining which 1s and 0s form which letter, while WordPress was writing UTF-8 (the most common way to encode Unicode, a character set that can represent all of the world’s languages at once) data to the database. This was pretty broken, but as long as WordPress and the database were both continuing to do the same thing, everything worked well.
With 2.2, WordPress apparently made a big step along the way to setting things up using Unicode/UTF-8 as the basis (and thereby easing future problems and the lives of anyone writing in non-Roman scripts, or in languages using multiple scripts, like English and Arabic or English and Chinese). Unfortunately, it seems that the Fantastico upgrade assumed that all existing WordPress installs were set up with a UTF-8 database instead of a Latin-1 database, and upgraded some configuration information with that assumption. Now WordPress and the database were no longer continuing to do the same broken thing and were now, essentially, talking in different languages. So I got gibberish.
Fortunately, there seems to be a (fragile?) simple hack to “fix” the problem; the solution was Google’s first hit (now there’s technology working for you!) and the gibberish is banished. The real solution is to perform some complex database magic on my database to tell the database, “hey, your data is already UTF-8; now let’s actually claim to be UTF-8 without messing things up” and revert the hack, but until someone bundles up the magic as a WordPress plugin, I’ll live with the hack.
As an aside, there’s something to be said for installing everything yourself; there’s a steep learning curve and it’s often time-consuming, but that is often paid back in time saved when something goes wrong. Back in the late 80s my dad was starting his business and running it on Xenix (before SCO became evil), and he installed and reinstalled the OS over and over to get things right. Once he did, he could do it in his sleep when something needed to change or be fixed. The current system is a Solaris box configured and installed by a VAR, and last winter after Sun sent a guy out to replace a soon-to-be-dying hard disk and took the old one after leaving us with a completely blank replacement, it took 12-14 long and painful hours, with several hours of phone and email support from Sun (yay support contracts! 
), to get Solaris up and running again.
If WordPress (or Fantastico; I’m not exactly sure where the database configuration choice originated) had set the database up using a Unicode encoding like UTF-8 to begin with, this would have all been avoided. The moral of the story for software developers is this: always assume that users of your product will be entering data in many languages and scripts, so set your character set to Unicode and specify a Unicode encoding like UTF-8 from day 0. Doing so will save you and your users lots of pain over the years to come; dealing with “legacy” data for years afterwards is difficult, time-consuming, and no fun, and communication should be both easy and fun, all around the world.
(Final note to the Fantastico developers: if Fantastico can make an automatic backup of all the data before performing an upgrade, why can’t it also have a user-friendly “auto-revert” function that rolls back the upgrade and restores the backed-up data, instead of requiring the user to have ssh/shell access and providing a vague list of terminal commands to perform those same steps?)
Permalink
