“101 Fabulous Freebies”

Our stuff shows up under the “Get To Work” section.

Kudos to glazou for discovering this first.

While doodling on a pad today thinking about user interfaces, I started to wonder how I could demonstrate by UI that two sets overlapped and had common members. (In DOM parlance, this would be two ranges overlapping in the same document, or two overlapping selections.) Given a DOM node tree, how would you show that a node belongs to two different ranges? My solution: add in a few narrow columns to the left, and shade the columns by row for each selection. If two ranges overlap (or have adjacent boundaries), then put each range shading in different columns.

In other words, just add bars to the left of the main objective to show where the sets and their overlaps are.

So far, so good. But at the same time, I had this “brilliant” idea: why not make each selection’s shading in the column a different color? Read on for more details.

Continue reading Colors, combinatorics… and common sense →

This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
ben@***.com
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 9): 554 : Recipient address rejected: Access denied

I just wanted his expert opinion on something..

. 🙂

What Ben’s so serious about

Here at the office, I gathered everything I knew about XPI’s and confidently predicted that I could alter our new XPI packages to work with Firefox (they already work with SeaMonkey) in about a day. While that assertion still seems correct, it’s extremely annoying that I have to do so many things just to get it working.

SeaMonkey kept it simple: install.js and a few contents.rdf files, and on you go.

Firefox requires a few more files:

• install.rdf (I’m still not sure if it deprecates install.js)
• application.ini
• chrome.manifest

On top of that, the changes to the chrome package names make life really interesting. Now I have to overlay both chrome://navigator/* and chrome://browser/* as well.

I realize fully that at the time these “features” were implemented, SeaMonkey was not taken seriously by anyone but a few devotees (like myself). I also realize that SeaMonkey isn’t a primary project anymore

. I’m just griping, and I need to convince my boss to allocate some of my time officially to general SeaMonkey- and core bugfixing.

I’m not complaining that Aviary went and did their own thing. I’m complaining that the two are really out of sync. I don’t care which path either Aviary or SeaMonkey takes, just as long as they’re consistent.

Ah, well, maybe for SeaMonkey 2.0/3.0.

UPDATE: People are rapidly responding, touting the benefits of the Aviary API. Amen, I say to you, that’s not my point. My point, as a corporate extension developer, is that I shouldn’t need to work much harder to support both Firefox and SeaMonkey. I’d welcome as much as anyone else efforts to update SeaMonkey’s codebase to support the new API on trunk. (For the record, I do generally think the new API is better than the old one.)

XPCOM “Cheat Sheet”

I’ve had so much trouble over the last several days writing the XPath Generator algorithms that I started thinking. As a JavaScript expert and a C++ rookie, someone who knows IDL and can write components in JS with little trouble at all, there’s really no quick page that summarizes how you write XPCOM code in different languages.

So this is a starting attempt to write such a document. The goal is to come up with a bunch of simple tasks component authors must do, and write snippets of code demonstrating each of these in IDL, C++, JavaScript, maybe Python or Perl, etc. Suggestions (and especially cross-language examples!) welcome.

I’ve written the document in generic XML for now, just to give me a simple framework for adding Q & A for each one. Eventually, as this document evolves, we can transform it for DevMo to adopt

. I’ll make sure to cite each contributor. Links to currently-existing-and-accurate documentation would be nice.