But that's what Firefox and Thunderbird are marketed as: slimline but extensible. If I can make me an extension for faxing stuff from thunderbird, then I'll agree that the bar is set suitably low.
So I decided to write about my learning process, as I go, in the hopes that the documentation people might find some useful hints from my confusion, about ways to try to improve things.
The gateways I'll be writing the extensions for, if I ever get that far, are:
http://www-it.desy.de/support/help/uco_ ... ax.html.en
Now, where do we start? Oh, probably Google. "making thunderbird extensions"
That takes me to here:
http://www.mozilla.org/projects/thunder ... sions.html
Which has a link to a "mozilla.org tutorial" here:
OK, so I have to extract a bunch of xpifiles in order to write an extension. Uh... where do I find them?
Well it says they're in the chrome directory, so let's search for that... oh, I've 50 directories called "chrome".
Wait. This page is awful.
On operating systems with DOS-like shells, the following command accomplishes this task:
for %file in (*.jar); do unzip %file
Note that there are platform-specific files--en-mac.jar, en-unix.jar, and en-win.jar--in that directory. Extract only the one appropriate for your platform.
Blithering useless contrariness, mixing esoteric for-loopiness with an exortation not to use it because it'll extract the wrong files. No thank you sir, I shall find my tutorials elsewhere.
So I Google again: "thunderbird extensions tutorial".
Hrm, every single extension plugin tutorial appears to demonstrate how to put a hello world popup hanging off a menu item. Why is that? Does everyone want their extensions to do this? I don't have ANY extensions that do this.
Still, I find a page about extensions:
Looks good, it's a wiki, claims to be part of some "extension development documentation project".
That page tells me to read the page about setting up the extension environment.
The dev-environment page gives me some settings, and tells me to read a page about how to set environment settings, which in turn tells me to use about:config to set them.
Back on the dev-environment page, it then gives the same instructions to extract the xpi files, again without saying where on earth they might be located. This time, it just lists them as a bunch of *nix commands, some perl, and the instructions "(Windows users can use Cygwin to run these commands)"... well, I see red there and then. I'm sorry, but if these are the official docs, then clearly they were written by people with no clue, or a great desire to make the hurdle for developing extensions as high as possible. "If you wish to accomplish task X, install Perl, and Cygwin. Now you have three problems."
Anyway, looks like that section is for earlier versions of Firefox and Thunderbird. There are instructions for the later one:
"Simply edit the chrome.manifest the same way as described above"... except, chrome.manifest is not mentioned anywhere else on the page, so that's a dead loss right there.
Thankfully though, this is a wiki, so I can submit a change deleting the retarded cygwin plug, and providing easy commands to do all that and better in Windows... oh wait, editing requires a registered login, and the wiki login/registration page says "register on the form below", but there is no registration form. So much for the wiki.
I find these forums instead, and start writing this post.
OK, that was an irritating little detour, but I've got the dev environment vars set up, and extracting those xpi files was in the "Non-essential" section anyway, so I carry on my merry way back at the Dev:extensions page.
Now that tells me to read the "getting started with extension development" page. Okeydoke, time for another detour.
Looks like this "getting started" page is for 1.5 and later. Fair enough, it makes it nice and clear right at the top. I'm good with that. I've got me Thunderbird 1.5, so I'm good to go.
Heh it's another one of those "hello world popup from a menu" tutorials. Fair enough.
Sweet, there's a stub zipfile I can download, with all those little required files already set up, with the right folder structure. *save to desktop*.
Oh wait, it says that's the "development structure", and to package it I'll need to put it in a different layout, the "package structure", with a link to yet another page... nah, screw that, I just want to get into developing my extension! I've been at this an hour and not even got hello world working! What kind of crazy development environment is this?
Now onto the syntax. Yay, finally, into the meat!
Yeah, that all looks fairly self-explanatory.
And it even gives me a link to a "profile folder" page, answering the question I had back when they first started talking about extracting stuff in it: where the smeg is it?
It turns out it's in a hidden, unsearchable folder, located randomly outside the application directory. Cool. Intuitive.
Now it doesn't say so anywhere in this tutorial, but I'm guessing that line 8 of overlay.xul there has the name of the XUL element that it's going to verlay. And I guess that's defined in some xul file somewhere in the browser, whether in the chrome or the application directory, or embedded in some xpi/jar file somewhere, who knows?
So. I want to add a "Fax:" label to the dropdown list of mail targets in thunderbird. That should then override the behaviour of the ajacent textbox to validate a fax number, and fill out any missing parts of the address. It shoudl pull the fax number from the addressbook if only a name is given.
So to my uneducated eyes, it seems I need to find the names of the chrome elements that I want to overlay: that dropdown, and the ajacent address textbox.
To do that, I need to find and read all xul files in the profile and the application directory of Thunderbird, whether they're packaged in xpi or jar files or not. Hrm. There MUST be a more sensible way of doing that.
A quick rummage finds me a listing of chrome URLs, which says "To overlay an existing XUL element, you first need the URL of it's chrome." (learn how to write your posessives: it's "its", when it's posessive):
Which is great for firefox and mozilla, useless for thunderbird.
The original crappy tutorial at least suggests using the DOM inspector, so let's try that!
Now, where can I get a DOM inspector that works on thunderbird 1.5?
Yup, that works. We're cooking with gas now! So I open up the inspector from "tools -> dom inspector", click to compose a new email, click "file -> inspect a window" in the dom thingus, and select the composing email from the list.
Sweet, a DOM tree. Now how do I find the elements I want in that tree? Ooh, selecting elements in the tree makes them flash a red border on the window. That's positively sexy.
So I drill down: window -> hbox -> vbox -> toolbox(toolbar-top:headers-box) -> toolbar(MsgHeadersToolbar) -> hbox(msgheaderstoolbar-box) -> vbox(addresses-box) -> listbox(addressingWidget) -> xul:listrows (this one's in red, and it stops giving the cool flashy border hints here... but from here I can find my own way I think) -> xul:listboxbody -> listitem -> listcell -> menulist(addressCol1#1) -> xul:label.
So I've found my dropdown list.
Next to it is a textbox that probably holds the address.
The addressbar of the inspector reads:
I guess that's where I need to look to find names to override.
But I've been at this for four hours, so it's time to go out for a kebab.