12.31.09
Posted in Camino, Life at 8:05 pm by Smokey
Sitting at this end of the calendar, 2009 seems like quite a long year; I’m exhausted, and I hope 2010 will be less of a marathon. 2009 was, however, still a good year for Camino, and that is what my annual look back is all about.
- First and foremost, we released Camino 2, a significant new release with lots of great new features like Tab Overview, phishing and malware protection, drag-and-drop rearranging of tabs, Growl support, and new AppleScript features. As with all community projects, it took longer than anticipated, but based on the very positive reaction, it was well worth the wait.
- Stuart Morgan fixed the most bugs, while Sean Murphy wrote three major new features; Jeff Dlouhy, Christopher Henderson, and Ilya Sherman also contributed major features to Camino 2.
- Our localization teams stayed busy, so the Multilingual edition of Camino 2.0.x currently ships with 15 languages.
- In conjunction with the Camino 2 release, we rolled out a redesign of caminobrowser.org. Thanks to our friends at Clearleft for the design work, Samuel Sidler for implementing the redesign, and Philippe Wittenbergh for helping to polish the rough edges afterwards.
- While our focus was on Camino 2, we continued to release security and stability updates for Camino 1.6 throughout the year, and beginning in the summer we started landing code for what will become Camino 2.1.
- Dan Weber was our Google Summer of Code student in 2009, working on enhancing the location bar. Over the course of the summer, Dan implemented a new look for the autocomplete window as well as extending autocompletion to include URLs and titles of both bookmarks and history items (fixing a couple of the oldest remaining Camino bugs in the process). Check out a nightly build to see his work in action.
- Our hard-working localization teams added two new languages this year, Slovenian and Turkish, and revived two translations, Chinese (Simplified) and Danish that have been missing for several major releases. Sadly, a few languages didn’t make the jump to Camino 2, so if Camino is not currently available in your language, drop by the caminol10n project website, join the mailing list, and learn how you can help!
I think that about wraps up the high points of the year, in a little briefer fashion than years past. 
Thanks to everyone who was a part of the Camino community in 2009—developers, testers, localizers, and users—for a great year! We’re always looking for new contributors, so if you’d like to help make Camino even better, there are many ways you can help out in the coming year. In the meantime, enjoy Camino 2, Happy New Year, and welcome to 2010!
Permalink
Posted in Camino, History at 12:24 am by Smokey
This is a rather late reminder of the “pool” for the 2010 installment of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing contest (2010 Gecko browsers will be available in about 28 hours from now).
As I noted in January, the “three-peat” is Yahoo!’s to lose, although there was some talk last January of Yahoo! actually doing away with their date checking.
Get your picks in now for both the site/company that will break and the reporter of the Tech Evangelism bug who notices said site/company. (For the record, my picks are Yahoo! 
and Philippe Wittenbergh.) No actual prizes will be awarded, but both winners will be recognized in a future entry in this journal.
And remember: only you can prevent bad browser-sniffing!
Permalink
12.10.09
Posted in Software at 10:33 pm by Smokey
John Gruber points out a post by Basil Safwat that defends Google Chrome’s incorrect placement of the tab close button on Mac OS X. Safwat’s defense of the button is based on some nifty optimizations that Google’s engineers have made to their tab resizing behavior, such that users can continually hover in a single spot and close a large number of tabs with impunity, whether users are closing tabs from the right side of the tab bar or from the left side (see Safwat’s screenshots, if you haven’t already read his detailed analysis).
Like the old fixed-on-the-right-edge-of-the-tab-bar tab close button found in Mozilla and early versions of Firefox, and still seen today in SeaMonkey, I find this behavior very puzzling (actually, I found the Mozilla/Firefox/SeaMonkey version infuriating as well, since when I was mousing, I had to mouse over to the right edge of the window to a close any tab) and am surprised no one has questioned optimizing for it. That is, what is the use-case for serially closing a number of tabs—but not all of the tabs in a window—within seconds of each other, such that delaying the resizing of remaining tabs and the incorrect positioning of the close button on the tab are required? When I open lots of tabs, I typically handle them one by one, closing each when I’m done with it (often opening new ones in the process), and my cursor almost certainly won’t be sitting still in the same place as I interact with and process a series of tabs. Conversely, when I’m going to declare tab bankruptcy, there’s a great close button on the left side of my window to get rid of everything in a single click (well, two, since I have Camino warn me when closing a window full of tabs, but you get the idea), saving myself however many clicks would be required to close each tab individually, immediately after one another. I’m sure now and again I’ve accumulated a small number of throw-away tabs, but it’s never happened frequently enough that I’ve wondered if there were something we could change in Camino to make serial tab closing with the mouse more efficient.
When Firefox moved the close button off of the tab bar and on to individual tabs where it belonged, there were certainly complaints from adherents of the fixed-position button, but their arguments, to the best of my recollection of those long-passed days, were simply “the fixed button makes it easy to close a bunch of tabs at once,” without any explanation of how or when or why those users got themselves into a situation where they needed to close a number of tabs, but not all of them, right after each other.
It’s curious; why put so much effort into optimizing tab resizing after close and so flagrantly violate a cardinal rule of the Mac OS X UI grammar (in Gruber’s terms) that even the notoriously un-Mac-like Opera gets correct, to promote such a seemingly obscure set of browsing habits?
Permalink
12.08.09
Posted in Camino at 1:40 am by Smokey
Looking back, it appears that the last regular Camino update was in early August, nearly four months ago! As you’ve no doubt noticed, Camino work did proceed, and if for some reason you hadn’t noticed, I’ll let you know that we shipped three security and stability updates (Camino 1.6.9, 1.6.10, and 2.0.1), one milestone (Camino 2.0 Beta 4), and one major release (Camino 2) since the last update. We also launched a new website redesign, brought the total number of languages in the multilingual edition of Camino 2.0.1 to 15 with the return of Polish, and have attempted to keep up with all the comments (overwhelmingly positive; thank you!) and bug reports we’ve gotten since the release of Camino 2—all the while battling illnesses and holidays. Herewith a brief update on the smaller details of the past week or so.
- Stuart Morgan handled the major Camino code changes for 2.0.1. He got Mac OS X 10.6 and the Help menu talking again in non-English localizations, and he hooked up support for collecting emails in the Camino Crash Reporter (once email addresses are available for authorized users of crash-stats, we’ll be able to contact you for more information about your crashes when we need your help).
- Christopher Henderson wrote a patch to make the about:config context menu start working, which is handy now that we officially acknowledge that about:config exists. He has also been working on some history-related changes and on implementing some missing bits in
CocoaPromptService that the about:config context menu wants to use.
- Chris Lawson gave Christopher’s patch a review, and he also began working through our backlog of unconfirmed bugs, following up on those that haven’t seen activity for a while.
- Samuel Sidler and Philippe Wittenbergh have been polishing some of the slightly-rough edges of the new website design and doing their usual parts to help with bug triage.
- With the release work for 2.0.1 out of the way, I’ve also joined in on the website polishing and bug triaging. Mostly, though, I feel like the sprint to 2.0 and then 2.0.1 is finally done, so I can take a moment and breathe.
That’s it for now; we’re slowly getting back in gear for the road to Camino 2.1, but the number of exciting changes will probably be light until after the new year.
Permalink