04.30.07
Posted in Camino, Life at 3:46 am by Smokey
After a long day of working in the yard, I’ve just posted patches for review on the last two bugs we intend to take for the upcoming Camino release (our good friend ☃). We’re very close…to being at the point where we are only waiting on a stable version of Gecko. 
Dates for that are still up in the air, but the current plan is for us to release something for everyone to play with while we wait on Gecko, a sort-of “fake release candidate,” sometime “soon.”
In other exciting weekend news, Stuart finally nailed the thorny old bug that prevented most AppleScripts from working in Camino on Mac OS X versions prior to 10.4! The fix is in the nightlies already, will be in the release, and we’re considering backporting it to the final 1.0.x release for the folks still running on 10.2.8.
murph surprised us with a new patch on our most-hated international bug, the one that prevents Chinese, Japanese, and Korean users from setting font preferences correctly. The bug is so bad and we’ve, um, been unable to come up with a good patch for a workable work-around for so long that there’s actually a third-party prefPane available to fix the bug. murph revised waverider’s patch and early reviews seem positive. We don’t plan on taking this fix in the final release, but we’ll ship it in the first security update (and the final 1.0.x security update) instead.
A busy man, murph also debugged one of the scary crashes we have been seeing in some number in Talkback post-1.1b. He was able to discover with certainty that these particular crashes (often at startup) were caused by the third-party utility 1passwd (which explicitly states it is not compatible with nightly builds). After the crash that plagued 1.1b, we’ve been a little skittish about crashes with even a small number of the same stacks showing up in Talkback, and murph’s discovery that it wasn’t something we were doing made me feel a lot better about the state of things.
All in all, a good weekend, and that much closer to releasing. 
Permalink
04.25.07
Posted in Camino, Life at 5:07 pm by Smokey
I’ve had this post half-written in some form, picking up dust, in my Drafts collection for quite some time now. I was afraid I would have to pick it up after Colin’s post about making Mac Firefox not suck hit the airways, but it’s actually been unnecessary (although I’m doing it anyway, since it’s still an opportune moment to say most of what I wanted to say on the subject of Camino).
Why did I have this half-drafted? For about as long as I’ve been associated with the Camino project, any time there is a big post or thread somewhere about what’s wrong with Firefox on the Mac, there are always a large number of people who suggest things like “Mozilla should just discontinue Camino and focus on Firefox” or “Camino developers should go work on Mac Firefox” or the like, implying that Camino is somehow a millstone around the neck of Mac Firefox development. (They’re also implying that Mozilla has control over Camino or its developers, which is not the case at all.)
For the first time, this hasn’t happened. I’ve seen far more posts along the lines of “Mozilla should just scrap Firefox and rename Camino” or “Add extensions to Camino and kill Firefox” (as well as a comment asserting that Camino’s built-in ad-blocking is better than Firefox’s, even with AdBlock installed; it’s quite flattering, although I’m not sure even I could agree that the assertion is true). There has been a subtle, but significant, shift, in how Camino is perceived by the world at large, and that’s why I don’t really need to dust off that old post (in fact, by the time this is done, it will be a significantly different post).
So, why, then, does Camino exist, why do I use it, and why do I volunteer for the Camino Project?
First, some history. In the dark days of yore, there was Mozilla (and before that, Netscape Communicator). It was an “internet application” that was all things to all people and claimed to handle your entire internet experience (web browsing, email, newsgroups, HTML authoring, chatting, baking cookies, etc.). Mozilla was based upon a cross-platform framework, from the rendering engine (what draws the web pages) right up to the user interface. And while Mozilla was really good at drawing web pages, it was pretty bad at doing everything else, especially on the Mac. Enter Camino (well, Chimera, in February 2002), a Mac-only, browser-only product, designed to be fast and to look and feel like a Mac app, using real Mac UI elements, not a “cross-platform app” (which really means a Windows app, when you get right down to it).
As a footnote to this history lesson, several months after Chimera 0.1 appeared on Mac OS X, Phoenix (later Firefox) 0.1 appeared for Windows and Linux, with similar goals: make a fast, browser-only app for Windows and Linux, but continue to use the cross-platform user interface. Firefox was not available for Mac OS X until Firebird 0.6 in May 2003.
Why do I use Camino? A good number of these are the same as why I volunteer for the Camino Project, so I’ll treat them together. First and foremost, Camino is a Mac app, through and through. Not even “Mac-first,” but “Mac-only.” Camino is built by people who make Mac software; some of them have even been writing Mac web browsers since before Mozilla existed! The team cares about how every pixel looks, the content of every context menu, and every integration point with the rest of the Mac OS X universe (even if sometimes there are compromises with time and resources—that’s the only reason there’s no .Mac sync yet 
in Camino, for just one example). There’s no requirement that something look or work the same way as it does on Windows or Linux in case people use several different operating systems. Again, we’re Mac users. There’s no corporate agenda behind development; we get to build a browser which meets our own goals—which haven’t changed since 2002: a fast, lightweight, Mac-only, browser-only application that absolutely feels like it was made for Mac OS X. (Not “made by Apple,” but made for “Mac OS X;” there’s a significant difference there. In fact, as I‘ve mentioned before, we’re the browser for people whose initials are not “SJ.”)
So Camino doesn’t have every possible feature for every possible audience, but it is still powerful software. It’s very scalable and grows with you as your needs grow. Out-of-the-box, Camino is set up to do the things everyone wants it to do (except for blocking ads, because this feature works imperfectly and can break sites, so a user needs to make a conscious choice to enable it), but if you want Camino to use tabs, or to make links that would open new windows open new tabs instead, there are preferences for those (the latter coming in the next release, code-named ☃). But Camino’s feature set is not overwhelming at first use; it just works, and it scales well to advanced users as they need features. By comparison, other browsers targeted at “Everyman Mac User” have limited feature sets or have tons of features exposed right in your face. By contrast, the tabbed browsing preferences in ☃ are a thing of beauty (thanks Stuart!).
Gecko is the world’s most compatible and most standards-compliant rendering engine; it’s also big (try being either of those things alone and you end up big!) and there are some annoying Mac-only bugs, like crappy font rendering in some cases, but Gecko is still a strength. It’s fast—maybe not WebKit nightlies fast, but fast enough—and I don’t know of a single site I’ve encountered personally that didn’t work with Gecko. And Camino is the best-looking Gecko-based browser in existence.
Finally, I (and I think I can safely speak for other Camino developers here) work on Camino because I love it and because Camino is a great browser. We don’t work on it because we want to make everyone happy, or have the most users, or take over the world. We don’t work on Camino because we’re paid (aside from the occasional Summer of Code student, no one is getting paid to work specifically on Camino); we’re a small band of volunteers working on something we love. Going back to the beginning, when in the past people used to suggest “Mozilla should discontinue Camino” in favor of Firefox—even if Mozilla could do that, it doesn’t mean the Camino Project volunteers would go work on Firefox; we wouldn’t.
Why is there a Camino? If “Why Camino” hasn’t explained it sufficiently yet, then let me end with something from someone who has written more browsers than any other person on the planet, father of Camino, co-founder of Firefox, author of tabbed browsing in Mozilla, and Safari/WebKit hacker extraordinaire, Dave Hyatt:
“Let 100 browsers bloom. Let 100 schools of thought contend. Separately. ”
Permalink
Posted in Open Source at 12:13 am by Smokey
If you’ve ever been tired of hearing “Unfortunately, the current scope of the NeoOffice project is limited by resources to keeping a native version of OpenOffice.org running on Mac OS X” (goodness knows I’ve been tired of saying it, and I imagine Patrick, Ed, and the other members of the NeoOffice community have as well), today is an exciting day.
Patrick has just announced the NeoOffice New Features Program, wherein users can donate funds towards implementing a specific new feature. If you want a feature implemented, donate, and if enough of your fellow users also want this feature and donate, Patrick and Ed will implement the feature.
Right now there are two features available for donations—they’re feature requests that have been fairly common and would improve the level of Mac OS X integration in NeoOffice—use of the native spellchecker (where available) and integration of the Mac OS X Address Book as a native data source (right now if you want to use data from Address Book, this less-than-ideal process is required). Patrick and Ed have analyzed and scoped these features and have determined an approximate cost of implementing each feature; if the amount of money required is raised before the deadline (all funds collected for features that don’t meet the required amount will be refunded; PayPal sets a deadline on refunds), the feature will be implemented.
If the costs of the features seem prohibitive, please remember that 1) Patrick and Ed live in California, a place that has a ridiculously high cost of living, and 2) Ed has a full-time job, and Patrick must balance NeoOffice work with consulting work to keep his family fed and housed. Developing software, especially software as popular as NeoOffice, is not cheap. Historically, a number of major feature additions, like drag-and-drop support, have been funded by significant donations; for the first time, the average user has a chance to fund a feature even if he or she doesn’t have deep pockets.
What if your favorite feature isn’t on the list? Don’t despair; other features will be added for funding in the future, once Patrick and Ed have had time to scope them out and estimate the cost. A popular request since Patrick first announced his intent to begin this program is support for video (e.g., whatever QuickTime can decode), especially in Impress, and some interest has been expressed in supporting PDF as an embeddable image format (e.g., not editable, but similar to how EPS files are currently handled). If you have another idea you’d like to propose for future consideration, please start a new thread in the New Features Program forum (if no one else has started a thread on the subject already); one idea per thread, please.
If you have other questions about the New Features Program (not answered on the New Features Program page), please check out the thread on trinity explaining the program.
Update 2007-05-21: Showing some additional menus even when all windows are closed is also on the list now, another improvement to take more of Windows out of NeoOffice.
Permalink
04.22.07
Posted in Links, Open Source at 9:40 pm by Smokey
The developer(s) of Handbrake (an open-source application for converting DVD content to MPEG-4, e.g., for iPod Video or AppleTV) have written up a nice guide for end-users as to what open-source software is and isn’t.
By and large, the post is an appropriate characterization of every open-source project in existence, and it certainly is completely correct for 95% of all open-source projects out there (most of which are small single-programmer affairs). There are a few well-known software projects to which the entire post does not apply completely (corporate-sponsored OSS projects that are open-source in order to harness the “community” to improve the product and the bottom line, and projects that fall a little closer towards some manner of “cater[ing] to the needs, whims, or desires of end-users”), but even in these cases, the formula set out by the Handbrake developer(s) is still largely correct from an end-user perspective. If you’re not up for reading the entire post, the two bulleted lists provide a good summary and a quick read.
Since I stumbled upon the post today with some surprise at not having seen it before, and since I liked it so much, I wanted to make a quick post and “do my part” to give it some more exposure. (Who am I kidding? Only Sam reads this —and only to catch my typos.)
Thanks to the Handbrake guys for coming up with this great guide; it’s a must-read, and I wish I had known about it a month ago. If you are someone who uses open-source software, please consider reading it to be your homework assignment for the week.
Permalink
04.20.07
Posted in Camino at 8:45 pm by Smokey
We’ve been pretty quiet on the Camino front lately, but that doesn’t mean that we haven’t been doing much. Lots of things have been happening, but as we hunker down for the final push to release, we’ve been doing more working than talking.
Here’s a brief rundown of what has been going on in the world of Camino:
- The countdown to Zarro Boogs is coming to a close; as of this afternoon, there is only one blocking bug left, three nominations, and one additional bug targeted for the release. We’ll probably be code-complete next week and will then wait on Gecko 1.8.1.4 to stabilize before releasing. While we’ve been working on on fixing the last few bugs and applying polish, our localization teams have been hard at work readying their translations for the release, too.
- Flashblock for Camino. This actually shipped in Camino 1.1 Beta, but it’s a bit of a big deal and didn’t get as much press as it should have. Quite out of the blue and shortly before Beta, Bryan Atwood showed up with a patch to integrate the popular Firefox extension Flashblock into Camino. We were all very excited to see both the bug get fixed and a new contributor arrive, and we hope to see more patches from Bryan in the future!
- Mr Sidler goes to Mountain View. Since Sam’s blog isn’t showing up on blogs.caminobrowser.org right now, many probably aren’t aware that Sam has a new job on the Mozilla Corp QA team. This is a double win for Camino; not only does he work on making sure bugs in Mozilla code get caught and squashed, but his new day job means he’s around a lot more than when he had another day job….
- Last, and certainly not least, Camino and Summer of Code 2007. We’re fortunate that Camino has gotten one of Mozilla’s Summer of Code project slots for the second year in a row. It’s tabs again this year, specifically pinkerton’s long-desired “Tabsposé.” Jeff Dlouhy will be joining us for the summer (and, we hope, for some time after that, too). Everyone please give Jeff a warm Camino welcome; we look forward to the beginning of his project!
That’s about it for now. If you’re using branch nightly builds, be sure to let us know if you find anything untoward. So far everything looks good, so we expect to give you another great version of Camino soon.
Permalink
Posted in Open Source at 6:33 pm by Smokey
I began this post on 27 March, but due to some interruptions and, well, the month of April 
, finishing it sort-of dragged out.
Today [27 March], NeoOffice turns 2, or specifically, 2.1. It’s actually the third final release of NeoOffice (NeoOffice/J 1.1, NeoOffice 1.2, and now 2.1) but only the second major release. Over a year in development, this is the biggest and best NeoOffice ever, not compromising on its legendary stability while adding a number of the features most requested by NeoOffice users. The release is based on the latest stable OpenOffice.org codebase, 2.1 (which explains what happened to NeoOffice 2.0 “final;” when OpenOffice.org started giving their bug-fix releases new minor-version numbers, we synced the NeoOffice version number so that people don’t get confused about what version of OOo code is being used) and has all of the latest OOo bugfixes. 2.1 also includes code from the ooo-build and the odf-converter project, providing support for Word 2007 import, the only ongoing solution for using Excel VBA macros on the Mac, and some nifty Calc tools like Solver.
More importantly, though, NeoOffice 2.1 is much, much more pleasing to the eye. There are the new file and Akua toolbar icons, Patrick’s Cocoa Open and Save dialogues, and Ed’s amazing Aqua widget work. NeoOffice 2.1 arrives with the NeoWiki in five languages, so that tips, hints, and troubleshooting info is available in English, French, German, Italian, and Spanish. There is a great community, both at the NeoWiki and in the Trinity forums, that answer questions, write documentation, and generally ensure that anyone who arrives at the forum gets a welcome and helpful advice.
This release is made possible by the hard and creative coding of Patrick and Ed, all of the support, documentation, translation, and artwork from the community members, and the financial support from Early Access Program members and the major anonymous donor. Thanks to all of you for your efforts (especially those of you who had to put up with me at some point during the process ) and congratulations. NeoOffice turns 2(.1), and I’m sure there are more great things ahead.
Permalink
04.11.07
Posted in Camino, Life, Open Source at 2:11 am by Smokey
Bugzilla really needs a “blog-like” drafts feature.
I’ve been really busy lately, and with all the flurry of work going on in Cocoa Widgets right now (and with the switch to the Cairo-Cocoa widget toolkit before that), I keep running into bug after bug that I need to file. Unfortunately, filing a good bug report takes a little work—a good description, a simple testcase, and, especially for the Cocoa form controls theming rewrite, comparison screenshots between Camino on the MOZILLA_1_8_BRANCH and Camino with the new trunk code. It takes 15-20 minutes per bug report to do this, assuming that I don’t stumble upon other bugs in the process—and lately, when I file one bug, I file three. So I can’t easily do a bug report in pieces, in five minute blocks (like I write many of my posts here); instead, I have to steal a larger block of time—and hope I haven’t forgotten which bugs or what nuances I need to file in the interim.
I know it’s a pie-in-the-sky request; tracking and preserving drafts of bug reports for hundreds, if not hundreds of thousands (like on bugzilla.mozilla.org), of users would be a massive pain to say the least. But a volunteer QA guy can hope and dream, right (after all, this is افكار واحلام )?
And in the meantime, I’m simply keeping a running list of bugs to file, along with a few of their details, on a page on the Camino wiki. Isn’t the internet grand?
Permalink
04.06.07
Posted in Life at 1:50 am by Smokey
…is the cruellest month.
Permalink