Sometimes I miss my friend Zach.

Spent a couple of days looking at patches and doing reviews. Brian Ryner fixed a bug that I intruduced with my xremote checkin that was causing some crashes and a warning every time the browser would start up. That fix will be in 1.7, which is good. Spent a little time looking at jshin's pango patch. caillon's patch that makes the clipboard async is in the queue as well. (Chris just joined Red Hat and is going to be working on Mozilla for us. He's a Star.)

Fedora Core 2 (aka the current rawhide snapshot) couldn't make a working optimized Mozilla build until today with the gcc update that jakub put together. There was an upstream patch that dbaron pointed out that needed to be applied to our gcc branch as well. Kudos to all for making that work.

In other news tonight I got in a little flying in the clouds. The weather was perfect for it. It was warm with low ceilings and light rain. My usual instructor had the evening off, so I found another guy to do some flying with. We did four approaches - two at Lawrence, one at Beverly and one back to Bedford. They all went pretty well, no major screw ups. It was fun flying between the layers and actually having to fly the approaches because we wouldn't be able to get down unless we did. The Bedford approach in particular was flown almost down to the minimums before the approach lights were visible. There was almost no turbulence. In fact, it was some of the smoothest air I've flown in and there was very little wind. It was nice for my second flying experience in real IMC. Very different from the last time I was in the clouds.

Something you don't want to see in a METAR report:

KROW 082201Z 11009KT 10SM +FC TS FEW085 SCT110 19/11 A2983
RMK TORNADO B14 TORNADO E20 FUNNEL CLOUD B38 FUNNEL CLOUD E41
TORNADO B41 TORNADO E53 TORNADO B57 AO2 TSB01 TORNADO
VC WSW MOVG E TS OCNLLTGCG SSW MO

This morning I checked in checked in code that extends the x-remote protocol to allow clients to distinguish between various products [*]. This, of course, requires changes to clients but the changes on the server side are set up so that older clients will continue to work as expected.

I've also changed the clients that are included with the Mozilla distribution so that they can send requests to the right clients. The mozilla binary (or the equivalent firefox or thunderbird binary) defaults to sending requests to only a running instance that has the same product name as the default that has been compiled into the client. This means if you do a mozilla -remote 'openurl(http://www.mozilla.org)' and Firefox happens to be running, it will not send the request to the running instance of Firefox. Some might find this disturbing and unexpected but I'm sick of getting bug reports that include a dialog with a completely useless error message.

There's also a lightweight binary that's included with the distribution that is called mozilla-xremote-client. This client does not default to the browser with which it was compiled. It's important to note that this is different than described as above. The problem was that this little binary is compiled with all the various products and its name doesn't change. So it's easy to have a binary named one thing and it actually only talks to a running instance of another. So you need to explicitly tell it which product you want to talk to. For example:

./mozilla-xremote-client -a firefox 'openurl(http://www.mozilla.org)'
./mozilla-xremote-client -a thunderbird 'mailto(blizzard@0xdeadbeef.com)'

I'm probably going to end up sticking this in the Mozilla 1.6 packages that are currently in rawhide and will end up as part of Fedora Core 2. The patch is relatively contained and is contained in the bug. My hope is that we'll finally be able to have a drop down box for your default browser that allows you to say that you want to use Mozilla or Firefox or Epiphany or whatever and you won't get any false positives. Also, the new improved clients actually have error reporting via STDERR - something that was very lacking in previous versions. It still uses error codes as return values that will tell you in a general sense what went wrong, so older scripts that depended on that behaviour will still work as expected.

In other news, Scaled Composites has apparently recieved the FAA license required for a spacecraft launch. Pretty cool, these guys are making great progress. If you're a plane geek it's worth reading the test data for all of the test flights of the various components of the launch system. I never realized what an iterative process aircraft design can be.

* In reality, the protocol already supported this since you can stuff anything you want in the _MOZILLA_VERSION string. However, I was concerned that if you had anything in there other than a number it might make clients I've never seen angry. And not the good kind of angry. The bad I'm gonna stick you when we're along in the jail cell tonight kind of angry. Plus, of course, or products are no longer released in a linear fashion. We have various numbers and various products, sometimes with numbers that go backwards. (Firefox 0.9 is newer than Mozilla 1.6) Best to just change the way it's done and move on.

Brian Ryner suggested that I list some tips on how people writing or hacking on theme engines can set up their code so that it works well when Mozilla tries to render it. Seems sane and this seems like a decent forum to do so. First of all, a little background on what makes Mozilla a little different from your usual Gtk application with regards to theme handling.

Mozilla's rendering model is a little different than most Gtk applications. First of all, most of the rendering is handled by the layout engine and may be dispatched to the Gtk layer including the theme code for drawing. The target for that drawing is likely to be an offscreen drawable instead of a native window. Most Gtk applications are written using native windows and many theme engines as a result assume that they will be drawing only to a native window. When Mozilla invokes the drawing calls in the theme engines and uses its drawable as a target, an X error is the result.

A little more explanation as to why this is a problem. There are two different kinds of objects that you can draw to in the X Window System. These are the Window and Pixmap. When referring to them collectively the term Drawable is used. The collection of raw X apis for drawing include some APIs that can only be used on one or the other or both. For example, you can only use XResizeWindow() on a Window object because you can't resize a Pixmap once it's been created like you can with a Window. Some of these calls, like XSetWindowBackground() are actually used via various gdk_* apis and aren't portable to a Pixmap. So we have our first rule:

1. Avoid calls that can only use a Window or Pixmap as a target for drawing or querying.

The biggest offender of this is the Crux theme which included the copious use of gdk_window_set_background. Unfortunately, we've discovered that this code pattern has been replicated from the Crux theme into a lot of other engines, too. These themes don't work very well in Mozilla. So, avoid function calls that include "window" or "pixmap" in the name. You're bound to run into trouble.

The second thing to consider is the fact that since your theme drawing is being targetted at a larger drawable it's going to be drawn at a random location. There are some themes out there, like the Mist theme that apparently assume that if the drawable that's passed in is of a different size than what you asked to draw that there's a problem and quietly bail on the drawing operation. This couldn't be farther than the truth. Apparently this code has been used in other theme engines as well so we've got a problem with a lot of random themes out there. So, rule number 2:

2. Don't assume that the drawable that you're going to be drawing on is the same size as the drawing request

A final technical note about Mozilla's theme handling. If we dispatch out to the theme engine and it causes an X Error we trap that event and disable that particular UI element for that theme engine. This is why with some theme engines some of the UI elements are themed and others aren't, even when they are themed when using other engines. This also means that we can limp along under most circumstances even when we've got a theme that is misbehaving.

People are always complaining that Mozilla doesn't look "native enough". If people follow these two simple rules, it goes a long way to helping with that problem.