File this one under stupid Unicode tricks, I think.

A co-worker of mine was having problems remembering where the makefile puts the binary for Thunderbird when you build it yourself. Now, I type in the path far too often, so I know where it is (on my computer, anyways), but since I type it in far too often, I grabbed someone's zsh function that launched Firefox, and modified it to launch Thunderbird from either the build directory or the source directory, but only on Mac OS X.

Anyways, here it is, I hope some of you find it useful.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

thunderbird() {
  local -a currdir;
  currdir=$PWD:t;
  for nm in LanikaiDebug ShredderDebug Lanikai Shredder; do
    if [ -d "./mozilla/dist/$nm.app" ]; then
      ./mozilla/dist/$nm.app/Contents/MacOS/thunderbird-bin $*
      break;
    elif [ -d "../objdir-$currdir/mozilla/dist/$nm.app" ]; then
      ../objdir-$currdir/mozilla/dist/$nm.app/Contents/MacOS/thunderbird-bin $*
      break;
    fi
  done
}

I’ve been reviewing a patch from Andreas and Standard8 which adds lightweight theme support (aka personas) to Thunderbird. It’s so cool that I couldn’t resist taking a screenshot, and posting it for you all to see!

It looks like there’s a good chance the code will make it in to Thunderbird 3.1 beta 2, so with any luck, soon your Thunderbird will be a pretty as mine.

For the next version of Thunderbird, Bryan Clark, Andreas Nilsson, and I have done a lot of work to make it easier to upgrade your profile from Thunderbird 2, and we would like to hear what you think of it, and how we can make it even better.

There are some things we’re particularly interested in (mostly on the “Disk space” tab), such as:

1. Are your existing settings preserved?
2. If you have no previous settings do we choose “Do not Synchronize” by default?
3. For those of you who choose not to synchronize your messages, does that appear to work correctly?

We also have some more general questions, like:

1. Does it look okay? Do the sizes seem correct?
2. Do the options make sense, and how can we make them clearer?
3. Do the buttons work the way you think they should?

You can download the builds for various Operating Systems at the following links:

Windows

Mac OS X

Linux

And please leave your feedback on Mozilla Messaging’s GetSatsifaction Topic by the end of day on this coming Wednesday (April 7th), so that we have time to tweak the code and the design before the deadline.

Thanks!

For your reading pleasure this week, we have a guest post from Wei Xian Woo. Wei is a student working on Thunderbird as part of UCOSP, and has just had his first bug marked as FIXED. Anyways, that’s enough out of me. Here’s Wei’s post:

Programming Thunderbird in Visual Studio.

During this term’s Undergraduate Capstone Open Source Projects (UCOSP) Code Sprint held at the University of Toronto in January, I wrote a simple Python script for the Thunderbird team to make setting up a Visual C++ project for Thunderbird slightly easier for those of us working on Windows. Blake suggested making this script public so others could benefit from it, so here it is! The script is generic enough to be used for any project, not just Thunderbird. Feel free to use it and make modifications as you see fit :)

Using the script to create a Visual C++ project for Thunderbird

Create an empty Visual C++ project in Visual Studio.

From the command prompt launched by mozilla-buildstart-msvc9.bat, do:

python /path/to/refreshvcproj.py
--vcproj=/path/to/thunderbird.vcproj --dir=/path/to/gecko-sdk
--dir=/path/to/mozilla/comm-central/mozilla/xpcom
--dir=/path/to/mozilla/comm-central/mail

All files in the specified directories will be included in the project. I suggest including only the directories you will be working with.

Configuring the project for debugging:

Open the VC++ project file in Visual Studio, and then open the project's Properties.

Go to: Configuration Properties -> Debugging.

Set Command to pathtoobjdirmozilladistbinthunderbird.exe

Set Environment to XPCOM_DEBUG_BREAK=warn

And… you’re done!

For better C++ IntelliSense, you might also want to consider getting Visual Assist X (an add-on for VS).

Happy coding!

And you can find the script over here.

Thanks, Wei!

I’ve run into a bug. It’s a really annoying bug, because it prevents me from changing folders when I try to test any of my Thunderbird changes.

I tried putting dump statements everywhere, to see if I could figure out what was going on, but they were to no avail. Then, I thought about looking for the error code.

So the error lookup page says that the error that’s reported is:

Module          Severity        Number
CONTENT (25)    Failure (1)     6

And DXR says that Content Error 6 is: NS_ERROR_CONTENT_BLOCKED

Which occurs, among other places, here

But when I set a breakpoint there, it didn’t hit it. So instead of trusting mxr or dxr, I did a grep (well, an ack, but same thing), and started setting breakpoints on a few of the hits.

The one that hit my breakpoint ended up being this one which, weirdly enough, isn’t even listed in the mxr results of this search

Now that I’m at the breakpoint, we’re halfway there, I hope. ;)

How I got there was:

(gdb) bt
#0  nsDocShell::InternalLoad (…) at …/mozilla/docshell/base/nsDocShell.cpp:7643
#1  0x152d9daa in nsDocShell::LoadURI (…) at …/mozilla/docshell/base/nsDocShell.cpp:1369
#2  0x13dc7581 in nsLocation::SetURI (…) at …/mozilla/dom/base/nsLocation.cpp:316
#3  0x13dc8af3 in nsLocation::SetHrefWithBase (…) at …/mozilla/dom/base/nsLocation.cpp:595
#4  0x13dc8cf9 in nsLocation::SetHrefWithContext (…) at …/mozilla/dom/base/nsLocation.cpp:542
#5  0x13dc9120 in nsLocation::SetHref (…) at …/mozilla/dom/base/nsLocation.cpp:510
#6  0x003fa28e in NS_InvokeByIndex_P (…) at …/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
#7  0x120f88bb in XPCWrappedNative::CallMethod (…) at …/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2727
#8  0x1210c0c6 in XPCWrappedNative::SetAttribute (…) at xpcprivate.h:2550
#9  0x12105530 in XPC_WN_GetterSetter (…) at …/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1792
#10 0x001141a7 in js_Invoke (…) at jsinterp.cpp:1388
[…]

And it looks like we get there because the return value of NS_CheckContentLoadPolicy is 0x80004003, or NS_ERROR_INVALID_POINTER.

Then, after dinner, I tracked it down a little further, and if you place a breakpoint on the “\n\nAAAAAA\nrv5=%x\n” line in this patch, you can see that it’s the folder = do_QueryInterface(subFolder, &rv); line which is causing the failure, because the subFolder’s mRawPtr is null.

But I have no idea why that’s happening, so I posted what I had, and hoped that someone else could take it and run with it. And Bienvenu did, and now it’s much less of a problem for me, and I can go work on other things.

Earlier today, I was asked by Andreas Nilsson to give him a hand with a folder pane header bug he was trying to fix. In the middle of digging around in the code, I thought “I should really write this down, so that I can understand it later.”, and so here it is.

The main place we’ll need to change is in this object.

We start in the load method, which calls registerMode, to add the mode with its localized name. There is also a default list of modes, which will come into play later.

When the user chooses to cycle the mode, it calls the setter for mode, passing it the modename, which comes from the _modeNames list (which contains both the defaults and any newly-registered modes). Then, in the setter, if the mode is a default mode, it will fail the if-test, and get the localized name from the “bundle_messenger” string bundle. If it’s a newly-registered mode, they will have passed in a localized name which we will have stored in this._modeDisplayNames, and so we will use that.

The point of the bug is to switch the label-and-two-buttons to a dropdown menu, so at this point I think we should start with an empty menulist in the XUL, and in the load method add menuitems corresponding to the values in the _modeNames array. Then, in the registerMode and unregisterMode methods, we should add and remove new menuitems, which I’m hoping will just automatically show up in the dropdown. Finally, we need to change the setter for mode to not calculate the new name, but just select the appropriate menuitem set the mode attribute on the _treeElement, and call _rebuild(). At that point, I think we’re done, but only time will tell.

Okay, so this was really posted on Dec 22^nd, but I wanted to back-date it so as not to bump Amy’s “Welcome” post off the top a mere day after she posted it.

While I was at the Toronto iPhone Tech Talks, I attended the OpenGL ES sessions by Allan Schaffer. Seeing the “Shock” demo was really inspiring, and caused me to want to try my hand at some simple OpenGL Shader demos.

The base XCode OpenGL ES Application template sets you up pretty nicely for some simple experimentation, the only things that gave me any trouble were:

1. remembering to set the identifier to ca.latte.whatever so that I could build, and

2. remembering that the OpenGL ES 2.0 path only ran on the device, so of course none of the changes I was making were showing up on the simulator¹, and finally

3. Figuring out that depth was position.w, and not position.z. (Did I mention that I’m a bit of a newbie at this?)

Anyways, after it was all up and running, I made the x and w co-ordinates vary on a different period than the y co-ordinate, and now the square moves around in 3 dimensions in a pleasing (to me) way.

Since this is intended for me to play around with shaders, I’m not going to bother updating the OpenGL ES 1.0 code path, but if you’ve got an iPhone 3GS, or a 3rd generation iTouch, feel free to grab the code at BitBucket, and play around. I'll be adding branches and tags and keeping it updated as I play with new stuff.

A while ago I had my first patch to Thunderbird committed.

Today I pushed my first patch, all by myself.

It’s kind of exciting, having checkin privileges. It means that I don’t have to wait for someone else to check in my changes once they’re accepted. But on the downside, it means that I’m the one who has to do the commit, and watch the Tinderbox, and if anything goes wrong, I’m even more on the hook than I previously was. (Well, that last part isn’t really true, but I feel way more nervous than when I could just add “checkin-needed” to the bug, and not worry about it anymore.) And basically there’s just a lot of new stuff for me to keep track of, and figure out. But since anything I do is going to show up in the official history, I need to figure it out before I do it, which always adds a little pressure, which in this case is probably a good thing.

I’m always looking for ways to speed up my Mozilla build, since it allows me to test my changes even quicker. I was really excited when I found out about make -s tier_app, since it sped up my compiles by a huge amount.

make
real    10m22.630s
user    4m28.072s
sys     1m27.807s

vs.

make -s tier_app
real    0m14.426s
user    0m6.502s
sys     0m3.957s

But yesterday, on IRC, I heard about libs_tier_app, which is ever faster, if you haven’t changed any IDL files (which I usually don’t).

make -s libs_tier_app
real    0m9.407s
user    0m5.440s
sys     0m3.065s

Okay, it’s not nearly as good as going from 10 and a half minutes to 15 seconds, but a 30% (or is it 50%) speedup is still nothing to sneer at.

I’ve been doing a lot of work recently, in preparation for the next (and last!) beta of Thunderbird 3, and I’m happy to announce that it was released yesterday!

The reviews from LifeHacker and Ars Technica have been positive, which is always gratifying to see on something you’ve spent a lot of time on.

For more information, check out the Thunderbird 3 for Users page, or the Release Notes for beta 4.

Recently, I made some changes to my work flow to get around some slight annoyances. Specifically, I switched from using mq to using pbranch. The features that pbranch gives me that mq didn’t basically boil down to two main things; sharing, and tracking.

With pbranch, it’s way easier for me to share my changes, both with other people, and with myself in a virtual machine. It is possible to share the patch with mq, by cloning the patch repo if I remembered to run qinit -C, but with pbranch all I have to do is clone the main repo, and my changes are right there, waiting for me.

For tracking, when I’m nearing the end of a patch, and it mostly works, I get really nervous if I can’t check in my changes. With mq, I set up an alias to let me commit the patch queue, so that I could go back, but it was really hard to tell what I had changed between any two commits, since it was showing me the diff of my diffs. And so I didn’t use it as much as I would like to. With pbranch, I just commit the code, like I want to, and it keeps track of what the patch should look like.

So, my day-to-day workflow now looks more like this:
If I’m working on a bug that I’ve already got a patch started for, I cd to the appropriate branch, type hg pgraph to see where I am, and hq update branchname to get to the pbranch I want to work on. Then I make my changes, and when I’m happy with the results of hg diff, I type hg commit to put the changes into the pbranch. After that, I use hg pdiff > ../branch-name-bugnum-description.diff to get a patch that I can upload to bugzilla. At this point, I usually load the patch into Vim, and search for some of the mistakes I’ve made in the past. (/^+.*[[:space:]]+$, and /dump caught a lot of my initial mistakes. Now I’ve moved on to things that are tougher to check for, like putting open-parens on a new line instead of on the previous line.) I usually go through a couple of cycles of hg commit/hg pdiff … before I’m happy with the patch. Once I am, I don’t have to type anything before I upload it, since it’s already committed.

A lot of the code I write for Thunderbird has to work on all the platforms it supports. Since I don’t own a Linux or Windows box, and don’t really want to waste the hard drive space on my MacBook Pro with a dual- or triple-boot setup, I’ve decided to install the other operating systems on virtual machines. (I’ve chosen VirtualBox, because it’s free, and I’m cheap. As an added bonus, it works quite well, too.)

If I was forced to use a centralized version control system, this would lead to a bunch of pain, since I wouldn’t want to check in a half-finished patch, but I would still really want to see what changes I made for one OS, to try and figure out what changes I need to make for the others. And I would want to be able to keep a record of what I did, step by step, so that I could undo stuff if it turned out to be a bad idea. (Hey, that sounds like a perfect task for a version control system! ;)

Since Mozilla uses Mercurial, I didn’t have to deal with any of that. I had my repository on the host machine, which I had cloned from the main repo, and I just cloned it into each of the virtual machines. Whenever I started a VM, I pulled the latest set of changes from the host machine; As I fixed stuff on that platform, I committed to the repository on the virtual machine; And before I shut down the VM, I pushed my changes back to the host machine. When I wanted to see which changes I made to get things working for the platform, it was easy, and propagating those changes to the other virtual machines was also easy.

When people talk about the advantages of distributed version control, a lot of the time they mention being able to still commit your changes when you’re on an airplane, and sharing in-progress changes with other people, but for people like me who do mainly self-contained stuff and don’t fly anywhere, supporting multi-platforms with virtual machines and still being able to track my changes might just be the killer feature.

I don’t know what happened there, but it doesn't look quite right to me. Well, it’s fixed now, so I guess no harm, no foul, right?

It’s true, after a lot of hard work, and a few hard decisions, the first version of Thunderbird that has code of mine in it has shipped. Dan Mosedale has some comments on what’s changed. If you like Thunderbird, please download it, give it a try, and let me know what you think!

On a more personal note, the thing I did on this release that I’m the most proud of was to add a button that lets you reply to a mailing list.

I’m proud of it because it feels like a neat-but-still-usable UI, and because it is one more step on the road to getting people to change their mailing lists to not munge the Reply-To header. (With this patch, you are given the option of replying to the list, or the author. Unless the list has set the Reply-To to point to the list, in which case you can only mail the list.)

A couple of the other areas I worked on for this release were updating the Activity Manager so that it didn’t hang when you clicked “Clear Now”, and so that it merged a bunch of move/copy/delete notifications into a single notification that told you how many messages had been processed; and fixing a some layout and logic bugs in the Autoconfig dialog (which you get to from “File » New » Mail Account (Quick Setup)…”). Yeah, the Autoconfig dialog is still kind of ugly, but it’s better now than it used to be, and I’m working on making it prettier for beta 4.

A few weeks ago I started a new full-time contract at Mozilla Messaging (a.k.a. the people who brought you Thunderbird). I meant to post this on the Wednesday after I started, but didn’t get around to it until now. So, here you go, my notes from just after I started a new job.

It has been a pretty crazy couple of days, both because I’m not that used to working for a full 8 hours on one thing, and because I’m at the point where there’s still so much to learn that I could spend all my time researching stuff, and never get anything done.

But even with all the stuff for me to learn, I feel like I’ve made a fair bit of progress. There were a few bugs assigned to me, based on a previous patch, as well as a couple of things left to do to get the feature working, so I jumped right in to those. After I had new patches up for review on all of those bugs, I talked with Bryan Clark about what bugs I should tackle next. He and David Ascher both suggested that the new automatic mail server config dialog could use a bit of love.

This morning, I did some investigation on group email addresses for one of the bugs I’m working on, and took a look at how the autoconfig dialog was put together so that I wouldn’t sound like I was completely lost in the meeting. (XUL, CSS, and Javascript. No surprises there. :) Then, after the Status Meeting, Bryan and I chatted a bit about what the various bugs were that he had assigned to me, and what sort of things I might look into to try and fix them. A few hours later, I had a fix for one of them, and applied a similar fix to another. (As an aside, you’ve got to love the 3 hour investigation which ends up being a 9-character change. At least while investigating the bug, I learned a lot about hboxes, vboxes, flexes, grids, and descriptions, which will hopefully come in handy in future bugs. :) Finally, I ended the day by reading a review of a patch I submitted on Monday morning, making some tweaks to my code, and resubmitting it.

The final thing that amazes me is that each day is taking up pretty much a full page of my log book, which is way more than usual. Most of the days last month got a line or two. Really full days would maybe get half a page. But yesterday and today were a solid page, chock full of information, each. I wonder how long this trend will continue. I hope it keeps on going like this for a long time.

I have a theory. (No, it’s not bunnies.) One of my favourite foods is soy beans. I love it both because they’re tasty, and because they’re so changeable. I mean, what other substance can be used to make a hard white solid (tofu), and a viscous black liquid (soy sauce)? Hey, waitaminnute. “Soy beans” are oil! It’s all just different names for petrochemicals!

I started working for Mozilla Messaging a while ago, and since David Wolever asked me how I used Mercurial and the MQ extension, I thought I would put up some notes on how I’m currently using them in my day-to-day work. Of course, the stuff I’m doing now is a little different than what I’ve done in any of my previous jobs, so I’m not sure how useful any of the following will be to anyone who isn’t contributing to an open source project.

First, let’s talk a little bit about how I have my Work directory set up. The first thing I did when I started working on the Thunderbird source code was to pull down a clean copy of the source into a directory named “src-base”. The purpose of that directory is to always contain a clean copy of the upstream source code so that when I want to update the various branches I have (five, at last count), I only need to download the changes from the Mozilla repo once, and I can then propagate them from src-base to the other branches. I got the idea to do that from the Bazaar-NG developers, and I think it has helped to keep my bandwidth usage down. It might cause a problem if I was sharing my branches, but since Thunderbird seems to revolve around submitting patches to bugzilla, it works out pretty well.

The next thing I did was to clone src-base into a directory named “add-reply-list-button” (because I was writing a patch to add a Reply-To-List button :), go into that directory, and type hg qinit -c to create an mq repository, and put the mq repository itself under version control. (I didn’t actually do that the first time, and was quite annoyed that I couldn’t revert changes I had made in my patch queue.) The other part of that is that I’ve aliased mq to hg -R $(hg root)/.hg/patches. This lets me type mq commit to commit the changes to the patch.

So, now we’re at my day-to-day work. If I’m working on a bug that I’ve already got a patch started for, I cd to the appropriate branch, type hg qseries to see where I am, and hq qpush or hg qpop to get to the patch I want to work on. Then I make my changes, and when I’m happy with the results of hg diff, I type hg qrefresh to put the changes into the patch. After that, I use hg qdiff > ../branch-name-bugnum-description.diff to get a patch that I can upload to bugzilla. At this point, I usually load the patch into Vim, and search for some of the mistakes I’ve made in the past. (/^+.*[[:space:]]+$, and /dump caught a lot of my initial mistakes. Now I’ve moved on to things that are tougher to check for, like putting open-parens on a new line instead of on the previous line.) I usually go through a couple of cycles of hg qrefresh/hg qdiff … before I’m happy with the patch. Once I am, I type mq commit -m "Updated patch to fix foo and bar." to save the state of the patch, and then I upload it.

It took a while, but my first patch to Thunderbird was committed today!

changeset:   2727:98a7de404c08
user:        Blake Winton <bwinton@latte.ca>
date:        Fri May 29 10:35:37 2009 +0100
summary:     Bug 45715 - ""Reply to List" [button/(context) menu item]"
             [r=mkmelin,sr=bienvenu,ui-review=clarkbw]

The patch started off by adding a “Reply to List” button to the message header pane as seen below, but after some discussion, the scope was expanded to change the “Reply” button to “Reply All” or “Reply to List”, depending on the message you’re currently viewing.

Of course, there’s still some things I’ve got to add, but those can go in a separate patch, which will be much smaller, and so much easier to get reviewed and committed. And once it is, we might be able to close a 9-year old bug, which would be pretty sweet.