Its really hot in Minneapolis. It has been this way for almost 2 weeks. Almost every day it is between 90 and 100 degrees. I don’t have air conditioning, so its not fun times at my house. I’m going to hold out though – I don’t really like the idea of buying a big air conditioner and then using a whole bunch of energy to run it. I feel like I should face my own environment instead of fixing the problem by using up a bunch of energy. I’m well aware of the fact that my life is full of contradictions in this sense (e.g. how much I use my car), but whatever. I don’t want air conditioning. I’m hot and sweaty a lot but so long as I give myself something else to think about (hacking on Mozilla, spinning records, making my next cool drink) its not *that* bad.
The other day my friend Kristin and I went tubing down a river in western Wisconsin, maybe 45 minutes from Minneapolis. The three tubes we rented were actually the innner tubes for industrial truck tires. The third tube held our cooler full of beer, which we tied between our other two tubes with some twine. A rickety old bus drove us up the river for a while and dropped us off, and it took us almost 3 hours to float down. The river was somewhat speedy in some spots, really slow in others. It was pretty relaxing, just chillin’ in the river with our beer and floating by some pretty scenery. I definitely plan to do it again, even if it was the most hickish thing I’ve done in a long time. I love the midwest.
Here is an updated Cocoa Firefox build. It’s a Universal Binary this time so it works on both PPC and Intel Mac OS X. This build is stable enough for me to use as my everyday browser, but I have a high pain tolerance given that I am a developer. YMMV.
We would really appreciate it if people could report any bugs they find that are regressions from switching to Cocoa widgets. A good way to do that is:
1. Grab a recent trunk nightly build of Firefox
2. Grab this copy of Cocoa Firefox
3. Find bugs in the Cocoa Firefox build, make sure they don’t also exist in the Carbon nightly build (all nightly builds right now are Carbon builds), then report them as Cocoa widget bugs.
You can click here to see a list of all Cocoa widget bugs that have already been reported.
I’ve been spending a good amount of time this week planning changes to our NPAPI plugin architecture on Mac OS X. I have filed bugs and set up a wiki page to document this planning.
This first section of the wiki page describes improvements I hope to make to our plugin code for Gecko 1.9. Supporting NP_GetEntryPoints should make things easier for plugin authors and keep us in sync with WebKit. Using a slower idleEvent timer for plugins that are not in a foreground tab on the key window should help with CPU usage when people have lots of plugins in different tabs. Supporting Mac OS X NPAPI Drawing Models means we can support 64-bit plugins and allow 32-bit plugins to draw using CoreGraphics.
The second section points readers to the current revision of the Mac OS X NPAPI Drawing Models spec. It is not final, there will most likely be quite a few revisions and additions (in particular, an OpenGL Drawing Model). I have already started implementing some of it just to see how it goes, but I won’t be posting anything until the spec is final of course. This spec was originally created to solve the problem of 64-bit plugins on Mac OS X, but it actually also solves the more immediate problem of 32-bit plugins being able to use CoreGraphics and thus it has the general title of Mac OS X NPAPI Drawing Models. A separate proposal might eventually come out to modernize event handling data types, but that isn’t on the table yet.