This week’s Random Notes

Status Updates

Zach Church

I'm done making the changes requested on my patch, and now I'm just working on mozmill tests. But, I haven't been able to get the tests to pass even without my patch applied. So I thought that I may have had a broken build, so I tried running the tests against a newer build. When I try to run the tests against the newer version, none of them run! I talked to sid0 and he says the python version mozmill uses may have changed. Snow Leopard came with 3 versions of Python installed, and I've been unable to get mozrunner and friends installed to the python version that I think it's using (with easy_install-2.6). So now Blake recommended that I just work on figuring out why the tests in the version of Thunderbird that I can run won't all pass, so I'll be asking around in IRC.

Tim Miller

These last two weeks have undoubtedly been the two busiest weeks of my life. I'll spare you the details, but I have not found time to work on this beyond fixing some whitespace errors on the patch I previously submitted.

This week is not looking a lot better for me with 2 more projects due. Hopefully around Friday I will have some time.

Marcel Guzman

This week I spent on other courses (midterm and essay = bad) but I will have all of next weekend to work on Thunderbird!

Kefu Zhao

This week I received Blake's code review on the patch I submitted last week. Then I revised my patch according to Blake's suggestion, such as coding style and a small change on the algorithm that filters out "delivered-to" headers. After I refact my code and test, I submitted a revised patch, pending Blake's review again. :)

Lindauson Hazell

So the last problem I had was, the changes I was making through the mailUtilityOverlay.xul were not being realized in Shredder. That's been resolved -- I had multiple mailUtilityOverlay.xul files; I was editing the wrong one.

The next thing I started doing were tests -- disabling UI elements to see how such edits translated in Shredder.

The result was pretty inconsistent with what I thought should have been: Disabling a menu items in the mailUtilityOverlay.xul did not necessarily disable that menu item in Shredder. In fact it was hit and miss.

It took a while, but after reading a bit (and being totally confused for awhile) I think I understand: I'm assuming the mailUtilityOverlay.xul only acts as an instantiator, the state of the menu items may be changed, by other entities. I have two theories now:

1. Not instanciating the menu elements to "disabled=true" results in these elements being enabled when they shouldn't.

2. I've been searching comm-central for a while now, and I haven't seen these elements instantiated, or even mentioned anywhere else. Maybe that's the reason these are not being correctly enabled -- they are not referenced anywhere. (I know that doesn't make sense, so why do they work?)

I don't know, I'm not sure, what I can try next, any suggestions, are welcomed...

Evan Stratford

This week:

• Pushing finished patches is understandably preferred to having several unfinished patches out there, so I'm looking now at finishing off the vCard import and export patches.
• I've been cleaning up my vCard export patch. dmose wisely pointed out that vCard support is incomplete; exposing vCard export to the frontend is likely to lead to unintentional dataloss. I removed the vCard export functionality from frontend, instead exposing a new method exportDirectory() in nsIAbManager; this takes the directory and exports it to a string. exportAddressBook() then wraps this to display the dialog and dump the serialized directory to file. I'm waiting for comment from dmose and others as to whether this is sensible; if this approach is extended to individual nsIAbCards, it might help clean up large parts of the export-related code in Address Book (and would also make certain functions like attaching address book entries to email easier.)

Wei Xian Woo

As mentioned in last week's report, I was working on a patch to incorporate the changes suggested by asuth. The patch is now submitted. With this new patch:

• Persisting session state for all open 3pane windows in the case when the user quits via the file menu is now handled correctly. In last week's report, I said we needed to listen to the "quit-application" event to do this but I was wrong. In this case, by the time "quit-application" is generated, all windows have already unloaded. Looking at [1] reveals that we can accomplish what we want by listening to "quit-application-requested" or "quit-application-granted". I chose "quit-application-granted" because other observers of the former can cancel the shutdown and a shutdown session persistence would not be required then.

• The public API of the session store manager is now much simpler.

• The load/unload logic of the 3pane window is now a lot simpler. In previous revisions of my patch, a 3pane window instance needed to know if it is the first 3pane window in Thunderbird. This is no longer required as the session store manager initializes itself if its not already initialized when the first window calls its |loadingWindow| function.

• All functions now use the named format syntax to aid in debugging.

• Unit tests that don't sleep for 5 seconds between each test. The unit tests now clobber the default interval used by the session autosave timer so the tests are as close to instantaneous as possible.

In addition to the aforementioned points, there are also other minor changes like more informative comments and the renaming of some functions to use more descriptive names.

While waiting for another review by asuth, I will be switching gears back to investigating the standalone message window.

Who’s writing the blog post this week?

Marcel Guzman