06.24.08
Posted in Camino at 12:05 am by Smokey
Just a brief report on some of last week’s progress:
- Sean Murphy posted an updated version of his anti-phishing patch, as well as a patch that adds the ability for Camino to perform useful action when a user clicks on a XUL button in the content area (buttons which have been proliferating with the move to introduce new error pages for every error type).
- Chris Lawson worked on a few Preferences window-related bugs again last week.
- Over the weekend Samuel Sidler switched one of our G4 minis over to build the
MOZILLA_1_8_BRANCH (as we continue to await the return of our Xserve, which went AWOL in late May), so we once again have nightly builds of what will become Camino 1.6.2 in the near future.
- Towards the end of last week, I gave Ted Mielczarek a few ideas about how to address bug 406088 (make the Mozilla Crash Reporter work better for right-to-left languages) on Mac OS X. I also began preparations for the Camino 1.6.2 release, including compiling the release notes and putting them up for review. Over the weekend I also created a patch that causes Camino to use some
.css files from toolkit/themes/pinstripe/ instead of from the old mozilla/themes, which will lead to better appearance of the aforementioned XUL buttons, among other things.
That’s all for week 25. If I have the time, there might be another summary next weekend; otherwise, this feature will resume after my return from Europe.
Permalink
06.16.08
Posted in Camino, Uncategorized at 10:57 pm by Smokey
I mentioned previously that WWDC and the Camino Meet-Up would probably lead to less Camino work last week, but that wasn’t exactly the case; there was still enough interesting activity for me to write up a brief weekly summary.
- Mike Pinkerton, Stuart Morgan, Nick Kreeger, Jeff Dlouhy, and Peter Jaros all attended WWDC and presumably learned lots of valuable information under NDA. Our fearless leader also pulled a tree on whatever laptop he had with him for the conference, so it’s possible he’s up to something.
- About two-thirds of our active development team made it to California for Saturday’s second-annual meet-up. In addition, Desmond Elliott was patched in from across the pond via voice and video chat, and I joined the video chat during the afternoon. Samuel Sidler will write more about the meet-up, and post a summary to the wiki, in the coming days. There were many fruitful discussions, but, as I understand, the real highlight for Jeff was finding out that I was not, in fact, a figment of everyone’s imagination or some form of artificial intelligence.
- Chris Lawson worked on various bugs over the course of the week, including a patch to remove more Windows ampersand shortcut marks from Core strings that are passed to our alerts. He also worked on fixing a few bugs in our HTML bookmarks importer until Stuart decided to take the old importer out behind the woodshed and put it out of its misery.
- Stuart started fixing some of the lingering problems preventing our chrome from being completely compatible with Apple’s accessibility API, moved most of our menu code over to a newer API, and started working on a replacement for the aforementioned HTML bookmarks importer.
- When he wasn’t on the job or representing Camino at WWDC parties, Sam continued bringing up our replacement tinderboxen (with help from Mark Mentovai on a pesky Ts timeout); we now have two G4 minis cranking out builds while we await the return of our Xserve.
- My contributions for the week were some assistance with the tinderbox configs, a handful of checkins, and finishing the May ad-blocking bug, as well as a bit of the usual triage.
In spite of all the conferring taking place, we weren’t standing completely still on the code front last week. Hopefully this week will see an end to our tinderbox woes and development on Camino 2.0 Alpha 1 can resume in earnest!
Permalink
06.15.08
Posted in Camino, Life, Software at 4:28 pm by Smokey
Ever since I upgraded to Mac OS X 10.5, I’ve been unable to share my 10.5 Mac’s files with any of the other Macs on my local network. This is despite the firewall claiming that AFP is an “allowed service” and happens regardless of whether the firewall is on or off. (My “solution”: continue sharing the disk in my 10.3 Mac, where enabling file sharing Just Works™, and mount that shared volume on the 10.5 Mac.)
By contrast, I joined the second annual Camino Meet-Up remotely yesterday afternoon, and though I’d never used iChat before, all I had to do was open the app and tell Sam my old mac.com username. Poof, there were pink and the gang in San Francisco and Desmond across the pond, all staring back at me and chatting away. No messing with the firewall required.
It’s obvious which task Apple believes is common and therefore optimized. I have no arguments with making video chat completely seamless, either; it’s just that file sharing used to be the same way, from early Mac OS versions all the way up until the arrival of 10.5—why did Apple have to break that?
Permalink
06.10.08
Posted in Camino at 1:38 am by Smokey
Some of you may have noticed it’s been some time since I’ve posted a weekly update on Camino—just over two months, in fact, although there have been a few Camino news posts in the interim. It’s been a busy couple of months for me, so the updates haven’t been on the top of the stack for a while. For the moment, here’s a brief update on what we’ve been doing.
- We released Camino 1.6 and 1.6.1, in 13 languages (though we’re still missing British English and Slovak from the 15 that were in 1.5.x). Samuel Sidler and I updated the website for all the changes and new features in Camino 1.6.
- Sean Murphy fixed a number of issues with our OpenSearch implementation for 1.6.1. When not working on those bugs, he has been hard at work at our phishing and malware prevention implementation; he attached a complete patch last week.
- Chris Lawson jumped back into our preference pane documentation and updated both the text and sample code. He also helped restore our support for a much-used but deprecated AppleEvent in 1.6.1 and has been working on some preferences window and location bar bugs.
- Bryan Atwood recently posted an updated patch for implementing the Flashblock whitelist; it’s currently awaiting review.
- Desmond Elliott (of scrollable tabs fame) has started looking into getting OCUnit set up and some tests written so that we can start unit-testing our own code.
- Stuart Morgan tag-teamed with Sean on the OpenSearch bugs, supplied a few other fixes for 1.6.1, and has been driving the Camino 2.0 Alpha 1 bug list. He landed a few Tabsposé fixes and is currently working on upgrading our version of Sparkle and rewriting our security UI to adapt to trunk changes. Stuart also continued providing milk and cookies to the update system on release days.
- As always, Mark Mentovai has been our fearless build-wrangler, build-stager, tinderbox guru, and the final word on the text of our release notes.
- Sam has been wearing his IT hat recently, coaxing better performance from our webserver and helping track down problems with our tinderboxen. With some help from Mark, Sam restored trunk nightlies by coaxing our 1.24 GHz G4 Mac mini into building. Whenever Sam is done with his IT hat, Philippe Wittenbergh has a few improvements to the website content and style waiting for him to review. In his free time, Sam has also been organizing our second annual contributor meet-up this weekend.
- When I’ve had blocks of time for Camino that haven’t involved releasing new versions, I’ve been fixing a number our various website content bugs. I’ve worked on a few miscellaneous bugs as well.
Whew! That’s a quick summary of the past two months of Camino development.
Most of the team is in California this week, either for WWDC, our second-annual meet-up, or both, so between that and our run-away tinderboxen, it’s unlikely to be a busy week, code-wise.
I hope to get back to updating on a more frequent basis, but regular weekly updates are unlikely to resume until I return from Europe in August, at the earliest.
Permalink
06.07.08
Posted in Camino, Software at 5:05 pm by Smokey
It’s pretty rare that I write about a technical topic (or even a mostly-technical topic), since I’m not really what most people would consider a “developer.” When I have written about such things in the past, it has generally been surrounding our feed handler applications, and this time is no different.
Because the feed handlers function as faceless background applications (they simply receive an open location/GURL event, do a tiny bit of processing, then send Camino a open location/GURL with the URL of a web-based feed reader and a feed, and quit), users have the best experience when they don’t even really know the handlers exist. That is, users don’t see the feed handlers launching, and the apps don’t steal focus from what the users may be doing when the apps launch.
Often Mac developers use the LSUIElement key with a value of 1 in their application’s Info.plist to make their application “hidden”—it won’t appear in the Dock or the application switcher—but this doesn’t make an application a real background-only application; if the application has windows, those will still appear (for example, the Mac OS X crash reporter behaves like this), and applications like this can still steal focus. If you have an application that periodically launches and “does stuff,” like Camino’s feed handlers, there are lots of chances for unfortunate focus-stealing.
The solution to this is an alternate property list key, LSBackgroundOnly, for “faceless background applications.” Set this to key to 1 and all is well, right? In most cases, yes; all is well. However, if your application is an AppleScript, as Camino’s feed handlers are, you’ve just set yourself up for a world of random hurt. AppleScript has this old feature where applications configured not to show a “startup screen” (as faceless background applications would be) can still be forced to show the startup screen on launch (if your application does not have a custom startup screen because you never intended for it to show a startup screen, you get a startup screen like this gem 
).
This override-the-decision-not-to-show-a-startup-screen is triggered by whether or not the Ctrl key is pressed when the application launches. In an LSBackgroundOnly application, any UI displayed by the application is stuck in this limbo z-layer, where it is sort-of visible if you move other applications out of the way, but never focusable (on 10.3.9, the startup screen isn’t even visible at all!). As a result, if your LSBackgroundOnly AppleScript application launches when the user is pressing the Ctrl key (in any application: Camino, Finder, Terminal, etc.), the startup screen appears and can’t be dismissed, preventing your application from running or quitting. Yikes! The only way to terminate a stuck LSBackgroundOnly AppleScript application is to use a terminal command or Activity Monitor; neither is very user-friendly, and both assume that your users can figure out what’s happened in the first place.
As a result of this old AppleScript (pointless—why would you ever want to show a startup screen in an application you’d explicitly saved to not have one?) behavior, the user-friendly, impossible-to-notice faceless background-only application becomes a very visible, very unfriendly application staring your users in the face, taunting them because it can’t easily be closed—and, to top it all off, your application isn’t really running, so it can’t even perform whatever function it’s been designed to perform. Unless you can be perfectly sure that your users will never be pressing the Ctrl key when your application might launch, you will find that AppleScript is unsuitable for creating faceless background applications. 
Ultimately, someone else will probably rewrite Camino’s feed handlers as tiny Cocoa apps, but for any Apple types out there, I did log this behavior as rdar://5962612 and suggest that LSBackgroundOnly AppleScript applications ignore the Ctrl-to-force-startup-screen behavior (though based on other, less painful, problems this causes, I don’t think many would cry if the Ctrl behavior were sent the way of Mac OS 9).
Permalink
05.21.08
Posted in Camino, Life at 1:06 am by Smokey
You may have noticed that we released Camino 1.6.1 today. It was a bit of a long day for me, so here’s a light “by-the-numbers” post.
- 41
- the number of files on caminobrowser.org added or modified in support of this release
- 18
- the number of characters added or changed to update all of our version-specific messages (by comparison, several hundred characters across four files were required for the 1.5 website; thanks, Sam!)
- 14
- the number of minutes it took Mozilla’s Nick Thomas to get Camino 1.6.1 into Bouncer after Mark filed the bug
- 13
- the number of update feed files Stuart generated
- 4
- the number of Camino 1.6.1 MultiLang disk image iterations that Marcello packaged and I QAed
- 3
- the number of disk images Mark staged
- 2
- the number of languages added in 1.6.1 (Czech and Spanish)
- 1
- the number of release candidate builds for Camino 1.6.1
- 0
- the number of things I forgot to change in the blog posts/feed (my favorite statistic!)
Thanks to the whole team for all of the hard work on this release, especially the localizers who came through with post-1.6 string changes, localized feed texts, and returned Spanish and Czech to the multilingual version. As always, we hope everyone enjoys the new version!
Permalink
05.13.08
Posted in Camino, Life, Software at 11:06 pm by Smokey
Flash is already ill-regarded by Mac users for its wretched performance, detested by Linux users for its proprietary nature, and disliked by millions of web users for its general annoyance factor.
The larger problem, though, is that Flash breaks the web and defies established conventions that make the web usable. There are no hyperlinks per se (only clickable spots), no way to determine where clicking will take you, and no way to get back there (that is, no URIs or URLs). Even worse—and one of the reasons Flash is so beloved by certain types of content creators—Flash is a black hole; nothing comes out, which makes Flash entirely inaccessible for reuse, collaboration, or whatever the next great idea on the web is.
Case in point: we’re headed to Oslo this summer for a wedding, and the happy couple are registered at (surprise, surprise) a Norwegian retailer of fine table- and kitchenware. Part of the registry website is plain-old HTML, which means the non-obvious Norwegian words and phrases I encounter can magically become mostly-intelligible English words and phrases thanks to the wonders of Google Translate.
The other part of the store’s registry website, unfortunately, is a series of Flash objects. These are completely opaque to anything that reads the web. Google Translate can’t translate the “button” labels, and I can’t hover over the buttons to see where clicking them will take me (or even inspect the page source to learn the destination, which slightly crazy people have been known to do in order to get useful information). I can’t copy and paste the “button” labels into Google Translate, because, for all intents and purposes, they’re bitmaps, so if I persist in my efforts to have Google Translate decipher the site for me, I have to manually enter some Norwegian text (no non-ASCII characters on these buttons, thankfully). It’s painful, and it’s frustrating that what would “just work” in standard HTML has become a chore that only the most crazed or desperate among us will actually stick with through completion. What’s worse, there seems to be no compelling reason for the “buttons” in question to be Flash; unless the site intentionally desires to obfuscate the destinations of each “button,” the only “functionality” provided by Flash is a hover effect. :hover, anyone?
Perhaps you’re thinking, “this is an unusual/rare/contrived situation; there’s no real-word applicability here.” Unusual or rare, sure, but why cut yourself off from the opportunity to be useful/profitable from every situation presented (Occasionem oblatam tenete —Cicero), when you could just as easily (or perhaps even more easily; surely HTML+CSS is easier than writing a Flash applet?) be open to them? Norwegian retailers don’t have to worry about making their sites accessible to non-Norwegian speakers; Google can do it for them, if only they would use real text, the real web, HTML. No expenditure at all would be required to get this added market, but the retailers could reap the benefits of a scenario they never expected.
Every day on the web, use-cases you haven’t thought of are appearing and becoming mainstream, and in the rapidly changing world of technology, do you really want to be left behind or have to spend extra time and money re-working your site to become compatible with the next great movement on the web?
Please, turn off the Flash.
Permalink
04.22.08
Posted in Camino at 3:47 am by Smokey
Many of you have noticed that we shipped Camino 1.6 without a Spanish localization.
Let me assure everyone that both the Camino development team and the Camino localizers were unhappy about this, too. However, all Camino work—development and localization—is done by volunteers, and schedules of volunteers do not always line up. This was exactly the case with our Spanish localization; it wasn’t going to be ready in time for us to ship Camino 1.6 as planned last week. We knew this in advance, and while we always hate to ship a Camino release without a language included in the previous version, we needed to ship 1.6 and we did have 10 other languages ready.
As of this evening, the Spanish translation is nearly complete, and the first review indicates there is not much more work to be done. I can’t promise you a new Camino 1.6 Multilingual build that includes Spanish by the end of the week, but it is safe to say that you’ll see Spanish in the Multilingual build very soon.
As always, if you’re concerned about the status of the translation of Camino in your language, please stop by the caminol10n project and see how you can help. You don’t need to have many computer/software skills, and some languages just need reviewer/proofreaders—the only skill required for that task is your language and the ability to use Camino!
We thank all of our Spanish-speaking users for their patience, and we do hope to deliver the Spanish localization very soon.
Permalink
04.17.08
Posted in Camino at 11:32 pm by Smokey
If you’re reading this, it means we’ve survived yet another major release of Camino. Today we released Camino 1.6 (codenamed ✈) after about 10 months of development. Our fearless leader has already written about most of the major new features in the release, but you can also check out our freshly-updated Features page. It has been a long(er-than-expected) journey, but we’re proud of all the work and are pleased to offer you a new stable release.
The road to Camino 1.6 began in May 2007, when Mark Mentovai cut the CAMINO_1_5_BRANCH for Camino 1.5 security releases and the first fixes for 1.6 landed on the MOZILLA_1_8_BRANCH even as we finished work on Camino 1.5. Over the course of nearly a year thereafter, Camino contributors fixed nearly 400 “bugs” (problems or new features), and 18 different people contributed patches for this release (with Stuart Morgan leading at 153 fixes). Big thanks to the half of that list of patch contributors who aren’t regular Camino developers; every little (or big, like multiple accounts support for the Keychain) fix helps make Camino a better browser.
If you remember back to my Camino 1.5 wrap-up, the number of bugs fixed in Camino 1.6 is lower, but this was designed to be a smaller release. The fact that the number is not that much lower shows that Camino 1.6 ended up being a bigger release than you might otherwise expect from a 0.1 increase in version number (we played the late-stage version number “game” before, but we opted not to do it again). No matter which way you look at it, Camino 1.6 is another major accomplishment for our all-volunteer, all-free-time development team.
Thanks to the efforts of our fabulous localization teams, Camino 1.6 is available in 10 different localizations in addition to US English, with Spanish expected to join that list soon. Sadly, we had a few languages that shipped in Camino 1.5 disappear on us, so if your language is missing, please stop by the caminol10n mailing list and see how you can help bring these localizations back. (The work doesn’t require much specialized computer/software knowledge, and some of the existing localizers have volunteered to mentor new or revived localizations. Last year new contributors successfully revived the Norwegian localization, which was in Camino 0.8 but disappeared from Camino 1.0; you and a friend can bring Camino to thousands of users in your language!)
Again this year I went to bed last night while our fearless webmaster Samuel Sidler stayed up to put the finishing touches on the home page, the Features page, and dozens of other bits around the website. Aside from some afternoon connection issues, the website update felt like it went more smoothly than 1.0 or 1.5 did (I guess it helps when you’re not completely re-designing a site or adding tons of new support content ). Special thanks to Stuart for his last-minute debugging and testing during today’s release.
What’s next? Those of us who have been working on the website and other release details are going to take a rest for a while. Most of the development team, which had only a few things left for 1.6 after last month’s Beta 4, have been slowly ramping up to work on Camino 2.0. There’s not much visibly new over Camino 1.6 in the nightly builds yet (lots of Gecko changes, and Tabsposé is there but hidden), but there are some great new features already in progress that you should be seeing in the coming weeks.
In the meantime, enjoy Camino 1.6 and let us know what you think!
Permalink
04.15.08
Posted in Camino, Life at 2:06 pm by Smokey
Just because I need a break right now and sometimes it’s fun to play along with Planet Mozilla: what does a Camino QA lead/website peer/tester/sometimes-hacker’s command-line history look like?
[Qalaat-Samaan:dev/trunk/mozilla] smokey% uname -a
Darwin Qalaat-Samaan.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
[Qalaat-Samaan:dev/trunk/mozilla] smokey% history | awk ‘{a[$3]++ } END{for(i in a){print a[i] ” ” i}}’ | sort -rn | head
24 make
11 cvs
10 cd
8 open
6 history
5 edit
4 patch
3 diffscrape
2 touch
1 svn
1 ls
1 cp
Notes:
- This is the sum for my six current active Terminal tabs from the tail end of One License to Rule Them All (Phase 2) on (I had to quit Terminal once I had the fix mostly complete because of some sort of corrupted environment setting). For the morbidly curious, there are another 11 open tabs for other branches and trees I haven’t built since restarting Terminal.
- If there were some way to track Coda saves and MediaWiki edits…that would tell the tale!
- Pretty much every launch of Camino to test something goes through Troubleshoot Camino these days, so all of those would-have-been
open path/to/one/or/another/Camino.app commands are also missing.
- Thanks to bz for
tcsh variant; otherwise I wouldn’t have been able to play along and take this needed break.
Permalink
« Previous entries