A carnival of technology

Some of you probably remember the fun (“fun”) that I had a while back with the differences between PAL and NTSC. To summarize, I bought a copy of the movie Fistful of Dynamite, which, due to some merging and selling of MGM assets before a promised release date, is not available in the US. The Internet suggests that there might be a Japanese DVD, but amazon.co.jp (a site that frightens me to my core) does not have it, so I bought a copy from the Great Britain. The end result of this trans-Atlantic commerce was me being in possession of a Region 2 PAL DVD which, even if I were to get around the small obstacle of region encoding conflicts, I am unable to play on my NTSC television. I may have mentioned to some of you that the bizarre Shinsonic DVD player I have seemed to be converting the signal, but this was me being stupid: I picked Once Upon a Time in the West off of the shelf, instead, and and I didn’t pay enough attention to the 12 seconds I viewed to realize that it was the wrong Western. I’ve now taken the path of least resistance and purchased a region-free PAL to NTSC converting DVD player from some shady shop in Illinois that also sells 50Hz AC ovens. I honestly have no idea why anyone in the US would need a large European appliance, nor do I know what sort of person would try to ship one. I do wonder if they offer an option of filling it with Quikrete before handing it to the freightline. Regardless, I’ll let you know how the player works once it gets here.

In other news, I’ve now entered the dark world of the Firefox extension developer; a stain will forever be borne by my soul. If you’re like me, the switch from Mozilla/Seamonkey/whatever to Phoenix/Firebird/Firefox/Deer Park/whatever was met with a lot of cursing, since most of those options from before that kept the browser from doing stupid, annoying things like making the URL bar pop up at you whenever you type something no longer had any effect. I used a hack in userChrome.css for a while, but eventually my dissatisfaction with a few other features led to me to move my chrome hacks into an extension which you can find at http://gophernet.org/projects/rmannoy/. My current goals are to make things stop freaking pop up all over the place, make the bookmarks toolbar folder go away, and make the password manager work on all sites whether my stupid bank wants it to or not. I’ve so far accomplished all of these goals except for the bookmark-related ones, so I slapped together a release before I lose interest and let the project die. The password feature isn’t in the release, either, since I just finished that and figured that two releases in two days (An incomplete attempt to take care of the bookmarks toolbar folder was interfering with other parts of the browser) is probably enough for a while. If you want this functionality, send me an email and I can send you a sooper seekrit pre-release XPI.

Extending firefox hasn’t really been the most fun ever. My process for any particular feature has been to use the DOM inspector in an attempt to find the offending pieces of the GUI, muck through the firefox source in an attempt to understand it better, and then search through xulplanet.com looking for the controls of the objects I don’t like and any other objects that may help me on my quest. The most fun parts, of course, are the ones that aren’t documented. For example, the password thing mentioned above is controlled by the use of an ‘autocomplete=”off”‘ attribute on HTML text input controls, a feature from IE that banks demanded from the Mozilla developers lest they withhold their official seal of support. Apparently this is important to people who care about market share and the other fickle winds of business. I found all of this out because jwz happened to feel as I do, that I don’t need web designers babysitting my saved passwords, and he posted about this in his blog along with a method for patching the browser binary. I found the event I needed to catch for content pane changes in the code for the greasemonkey extension. As far as I can tell, none of this is written down anywhere by the Mozilla team. According to that jwz blog entry, the means I use of getting my browser to do what I want interferes with Google Suggest, a site I had never heard of that uses autocomplete=off to keep the browser out of the way of their ridiculous hack. I do not care one single bit.

My main gripe with the whole extension development process is that I’m damn sick of writing everything in XML. The GUI definition files sort of make sense in XML, since I guess you could think of a window as a tree, but the paradigm starts to wear thin even with the GUI overlays. The idea with these things is to define a list of element in the document being overlayed along with new content to insert as children. So, at its best, it becomes, rather than a tree of GUI elements, a list of GUI trees, each rooted at an extant element from another document. This is the entire basis of the extension mechanism. Maybe I just lack sufficient XML team spirit, but this seems to me to be pushing it. At their worst, the overlays become what I used them for: an overlay document with a single element to pull in a javascript file and a single processing instruction to pull in a stylesheet. Everything interesting that can be done in an extension must be done through javascript, but the only entry point to any particular chrome file is the XUL overlay.

The stylesheet is even worse. XUL has a sister language, XBL, to add content, event handlers and dynamic properties to a XUL element, and these new XML files can only be added through a mozilla-specific style property. Worse, the XBL files are little more than a list of little javascript containers. Of the three types of grouping elements contained in a binding—content, implementation and handlers—two of them are done entirely through javascript. The XML around them does little more than name them. The content makes sense as XML, since it’s defining new XUL trees to add as the children of a XUL element, but wouldn’t it make more sense to add this ability to the overlay mechanism? Not everything needs to be XML. They would also do better to make the javascript parts more javascripty. There is a means provided for extending an XBL binding, but augmentation is accomplished through adding to the list or replacing the pieces of the original. Subclassing is an alien thing, and you will find none of that here.

Even the RDF files that tie everything together have no business being XML. I hadn’t really thought much of RDF before, but I learned through this research that the RDF XML file is nothing more than a representation for a list of three-element tuples. That’s it: subject, predicate, object. There is no structure beyond that imagined through shared subjects. Maybe I’ve become jaded about the whole thing, but when I think of the best way to represent a list, a tree isn’t the first thing that pops into my head.