02.25.08
Posted in Camino at 10:56 am by Smokey
Another week gone by, another week closer to ✈.
- Stuart Morgan was the busy man again this week, cleaning up several of our new features. He added support for OpenSearch auto-detection in the “Search the Web…” sheet and added an item to the search field menu that points to an (under construction) page with a list of search plug-ins, which will make it easier for everyone to install engines that don’t currently support auto-detection. Stuart also disabled the buggy tab progress spinners (again) and replaced them with a new static loading image. He fixed the icon for the menu that shows the list of all tabs so the icon now looks enabled instead of disabled when it’s available. Stuart also fixed the Find Bar so that it is less persistent and so that finding using
return functions more like Safari, and he updated its appearance on Mac OS X 10.5 so that it will fit in more appropriately there. Finally, he swapped the “Search the Web…” and “Fill Form” shortcuts for compatibility with the updated version of the HIG.
- Jeff Dlouhy continued working on tab drag-and-drop and did a quick review.
- Sean Murphy again reviewed Jeff’s latest tab drag-and-drop patch, and he posted updated patches for his OpenSearch follow-up bugs.
- This week I spent most of my time chasing down (or trying to chase down) regression ranges on a couple of bugs we’re working on, as well as doing a couple of simple reviews and landing a couple of patches.
Our queries reveal that there are currently only two 1.6b3 blockers and seven 1.6b3 blocker nominations, so we’re very close. See you again next week, perhaps even with a shiny new beta. 
Permalink
02.23.08
Posted in Camino at 6:45 pm by Smokey
It’s been a long time since the last entry in the Camino Tips series, but I’m back again with another of Camino’s hidden gems.
Have you ever found a non-clickable website address in another application, or stumbled upon some unkind site that mentions another site without providing a clickable link? If you have, you know that generally the way to view such a site is to select the address (URL), copy it to the clipboard, switch to Camino and open a new tab or window, paste the address into the location bar, and hit return. That’s six steps. Fans of drag-and-drop know that you can make sure Camino is visible, select the address, and drag it to the tab bar (or any tab widget or a page’s content, if you want to replace the current content of a tab) in order to load the site. That’s only three steps—much better—but you have to make sure both Camino and the other application are visible at the same time if you’re dragging a link from another application.
Enter the “Open URL in Camino” Service. If you’ve ever looked in the “Services” sub-menu in any program’s application menu, you may have noticed a long list of bizarre items, services that a particular application offers to all other applications on your Mac. Camino offers a service that lets you open a URL from another application, and the service can be invoked with a quick press of ⇧⌘U.
For example, select the URL below
http://caminobrowser.org/
and press ⇧⌘U; Camino’s home page should open in a new tab (or window, according to your preferences). Opening a non-clickable URL now only takes two actions.
Even better, the Service supports bookmark shortcuts, so if you have set up a shortcut for a search engine, you can quickly perform a web search from another application. Suppose you have a search shortcut “google” for Google’s search URL fragment (http://www.google.com/search?q=%s) and a friend sends you an email or instant message that reads, in part,
google Cairo for more info!
You can select “google Cairo” in your mail or instant messaging client and press ⇧⌘U; Camino will instantly load those Google search results your friend wanted you to see.
The possibilities are, well, not endless, but still numerous; experiment with the feature and enjoy faster access to plain-text URLs, bookmark shortcuts, and shortcut searches.
Permalink
02.18.08
Posted in Camino at 2:15 am by Smokey
This week we started to see the light at the end of the tunnel, the shiny glow of a brand-new ✈ (er, browser version).
- Stuart Morgan, Samuel Sidler, and I spent a bit of time this week triaging the ✈ bug list as well as the Beta 3 and ✈ blocker nominations. We pushed off a number of bugs that no one was working on that weren’t critical to 1.6 and prioritized others for 1.6 Beta 3.
- Stuart put together a number of patches for smaller ✈ bugs, following up on some of our earlier feature landings and some of our 10.5 UI polish (including a fix for the etched text in the status bar on 10.5, which wasn’t quite right once 10.5.2 appeared). In addition, he also reviewed a number of patches from our other contributors and chased after some less-than-straightforward issues from new bug reports.
- Jeff Dlouhy continued his work on tab drag and drop, fighting the tab dividers all the way.
- Peter Jaros spent more time fixing AppleScript bugs related to his summer work, including an accidental dictionary deletion that seemed to have been related to an OS bug on Mac OS X 10.4.
- Sean Murphy continued his work polishing our new OpenSearch support and did a couple of reviews, too.
- Nick Kreeger posted a new patch to get
window.blur working this week.
- After recovering from the releases of Firefox 2.0.0.12 and Camino 1.5.5 last week, Sam caught his breath and posted a preview of our icon touch-up. No, we’re not “refreshing” our icons to look like Windows or “re-imaging” them to look like Safari; the goal is to make the icons sharper so they stand out better on 10.5 while preserving the signature Camino look you’ve become accustomed to on 10.3.9 and 10.4.11.
- Stuart tagged me for reviews on a number of the bugs he worked on this week, and he also convinced me to take on a tiny bug in Obj-C land, which I did over the weekend. Besides that, my week was mostly triage and some mostly unsuccessful attempts at word-smithery.
This week starts off with a holiday in the US, so depending on everyone’s schedules, we might have a busier week or a slower one here in Camino-land.
Permalink
02.11.08
Posted in Camino at 2:09 am by Smokey
You can tell that the year is starting to come into its own and demand more of our contributors; it was another light week for us in the virtual land of Camino.
- If you missed the news earlier, we released Camino 1.5.5 on Thursday. Kudos to Mark Mentovai (build wrangling), Marcello Testi and all of caminol10n, and Samuel Sidler (website wrangling) for their fine work on getting the binaries in your hands.
- Mark continued providing advice and (super-)reviewing patches as I slogged through the various issues with feed handlers and the tinderboxen. He also landed another keyboard focus patch and did all the build-and-release work for 1.5.5 this week.
- Stuart Morgan wrote a couple of patches, tackled reviews from his queue, and chased after a few annoying bugs this week. Sunday evening he posted a patch to replace the problematic tab progress spinners with a static “loading” image for the short-term and tagged me with the review.
- Jeff Dlouhy posted new patches for enabling Quick Look in the Downloads window and for tab drag-and-drop.
- Sean Murphy turned around and sent Jeff’s latest tab dragging patch back with a number of review comments.
- Peter Jaros ultimately came up with the solution to the last problem with the feed handlers and the tinderboxen, and he reviewed my changes to the feed handlers AppleScript code to enable them to build successfully on the tinderboxen.
- Sam spent most of the week occupied by his Firefox 2.0.0.12 release duties, and after flipping whatever switches are required to unleash the new Firefox on the masses on Thursday afternoon, he turned right around and did all the website work required to release Camino 1.5.5. Sam also reviewed a couple of website patches over the weekend.
- I spent most of my Camino time this week trying to enable the web-based feed handlers successfully, but over the weekend I snuck in a couple of website fixes, updated Bryan Atwood’s nib for the Flashblock exceptions list, and did a quick review of Stuart’s spinner-replacement patch.
That’s it for this week; I’ll see you again next Sunday with another look back on the exciting world of Camino development.
Permalink
02.08.08
Posted in Camino at 1:31 am by Smokey
…the author of this post.
The title is a line from the license headers that are included with every new source file included in the Mozilla source code repository. While many people contribute lots of code to existing files, only relatively rarely does someone get to add an entirely new source file (and through that become an “Initial Developer” under the terms of the Mozilla Public License). Most often new files come about when someone adds a “major” new feature to a an application, which brings me to the next part of this post.
Tonight I checked in code that successfully enables Camino to build and ship support for passing RSS and Atom feeds to web-based feed readers (Bloglines, Google Reader, iGoogle, and My Yahoo!) for Camino 1.6. This is the most significant feature I’ve added to Camino (and the only one that wasn’t largely project and build system changes).
Observant readers (or those addicted to Bonsai) will notice I used “successfully” above; tonight was actually my third attempt at enabling the web-based reader support. Last Friday I initially landed the code, only to discover that osacompile on Mac OS X 10.5 supported UTF-8 source files while osacompile on 10.4 did not. I also happened on a problem where unify would sometimes choke on the .rsrc files osacompile compiled. In the process of discovering those problems, I also learned how to play with Mozilla’s CLOBBER support in order to clean out the broken feed handler applications that were causing unify, and thus the build, to fail.
On Tuesday night, with those problems fixed, I again tried to enable the code, only to discover another problem—unify was finding differences between the compiled .scpt files on the Intel and PowerPC architectures. After some investigation, I guessed that the latest problem was triggered by osacompile finding a different existing Camino when compiling for each architecture. Thanks to Mark Mentovai and Peter Jaros, we arrived at a solution that avoided causing osacompile to reference an actual Camino application at compile time and produced a script that ran on Mac OS X 10.3.9 through Mac OS X 10.5.1 (all of which ✈ will support).
For those of you who want no more technical details
, please enjoy the integration between Camino’s feed detection and your web-based feed readers! Special thanks go again to Mark and Peter for their help and reviews during the entire time I was working on the bug (and for Mark’s Makefile magic that solved the very thorny issue of creating multiple feed handlers automatically from the various input files).
For those of you interested in the technical side of the solutions that fixed the problems our tinderboxen were having with unify (the script that produces Universal binaries from two single-architecture binaries) and its interaction with products generated by AppleScript’s osacompile, here are the nitty-gritty details.
The first problem we solved was related to the .rsrc files included in each applet. For reasons that are well beyond my grasp, sometimes, but not always, the .rsrc would differ in ways only unify could see. The fix for this was quite simple; just DeRez the data fork of the .rsrc and then Rez the result back.
The second problem was more thorny. AppleScript likes to store a reference (including the full path) to any application mentioned in a compiled script. Unfortunately, on the tinderbox, new Camino applications are constantly created and destroyed, and with a Universal binary build, there will be more than one Camino. Combine that with the fact that LaunchServices will treat the copy of the application with the highest version number or the most recent timestamp as the “canonical” copy of the application, and you get a nightmare: each time osacompile runs, a different copy of Camino will be the “canonical” one. We had to come up with a way to refer to Camino indirectly, so that the compiled AppleScript would not attempt to find Camino until runtime.
If you are only looking to run on Mac OS X 10.5, this is very easy; you can send commands to an application using the application’s bundle ID (e.g., org.mozilla.camino). On 10.4 this capability isn’t present, except with a somewhat clumsy series of commands. However, on Mac OS X 10.3, that code errors when it runs; AppleScript’s support for the bundle ID is even more limited there. After banging my head around ways to make the code run on 10.3 without referencing a path (my standard work-around for indirect references on 10.3 is to get the path by means of the bundle ID, but in some cases the old-school bundle signature, a.k.a. the creator code, can also help you out on 10.3—unfortunately, not in this case), Peter finally suggested I define “Camino” as a property and then use the property when sending commands; success!
If you ever happen to be in either of these situations—and I hope you never will be—perhaps these tips will be useful to you. In any event, Peter’s solution struck me as clever, and I hope now I’ll remember it the next time I’m faced with some thorny application-referencing problem. 
Permalink
02.05.08
Posted in Camino at 10:17 pm by Smokey
Last week is a bit of a blur to me—I was consumed by non-Camino things—but I’ll do my best to reconstruct the week.
- Mark Mentovai finished his work from the previous week on making the build friendlier, landed a few more tweaks to software update, and cleaned up a regression on Mac OS X 10.4 caused by some of the recent keyboard loop changes.
- Stuart Morgan fixed the new Find bar so that incremental find works sanely, did reviews and super-reviews, and helped out with the backporting of a couple of patches for Camino 1.5.5.
- I have it on good authority that Jeff Dlouhy spent a good bit of time last week hammering more of our tab code into submission while working on the next iteration of the tab drag-and-drop patch.
- Peter Jaros posted new patches on the remaining AppleScript bugs targeted for ✈.
- Samuel Sidler has been serving as the lead for the Gecko 1.8.1.12/Firefox 2.0.0.12 security releases, and that release kept him more than busy last week.
- On Monday night I checked in our patches for Camino 1.5.5, with some help from Stuart in backporting a couple of the fixes. Tuesday night I worked on the release notes for 1.5.5 and was “pressed into service” by beltzner to do a last minute review on a Firefox build patch for their Beta 3 Release. Friday evening I went to land the patch for web-based feed readers, only to discover that
osacompile doesn’t support UTF-8 source files on Mac OS X 10.4 (while it does on 10.5) and that, for reasons that are still unclear, the .rsrc that osacompile generates during the build process can sometimes differ per-architecture. Fun!
After a weekend hammering on the problem (and some pointers from Mark), we have a more robust solution—let’s hope it sticks this time.
If I’ve missed anything, I plead “long, tiring week.”
Edit: Yes, among other things, I forgot that our downloads-and-feeds-wrangler, Nick Kreeger, has taken a position with our fine feathered friends in San Francisco. Congrats, Nick!
Permalink