A bigger toolkit, better tools

It’s semi-official: we are going to have a Mozilla 2.0.
I’m happy about that, somewhat. Sure, the number itself doesn’t mean a whole lot. But there’s been a lot of work done since 1.0.
Given that we are indeed going for 2.0, maybe mozilla.org’s contributors should consider adding new XUL (and XBL-based) widgets to the mix.
For instance, I’m working on an <xul:form/> element so that XUL can be a client-side user interface for a server-side application. XUL was originally designed to be the Mozilla chrome language, but HTML forms occasionally leave something to be desired. It’s a worthwhile goal, I think.
Seriously, I’d like to start creating widgets in XBL+JavaScript which Mozilla App Suite and its child applications (Mozilla Firebird, Mozilla Thunderbird, Composer++ to name a few) can start using. I’d really like to see others contribute such widgets, and maybe we can get a few of them in for Mozilla 2.0.
There are of course good reasons to not add every widget we come across (think code bloat). But a few good ones would be beneficial. I invite you to comment not only on whether or not widgets should be added for 2.0, but also widgets you can implement (but not widgets you’d like to see and haven’t got a clue how to do).
UPDATE: Turns out <xul:form/> wasn’t such a bright element name, so, here is a partially tested demonstration XUL file for <xul:serverpost/>.
Probably won’t work until Monday noon PST (thanks to bsmedberg for graciously hosting, though I had to fix a couple bugs and the corrected version won’t be there until then)
I filed Bug 231833 to implement this widget. Keep your fingers crossed…

Building blocks to a MathML editor in XUL

Bits and pieces
There’s three separate applets here, none of which is a full-fledged application. But it’s getting closer…
One of them, mathOverlay.xml, I introduced here back in June 2003. So that hasn’t changed.
The MathML_test.xul file is intended as a controllable user-interface for actually editing MathML expressions; the idea is that the selected overlay will replace a white textbox in the master expression, and the text in the master will go to the matching white box in the overlay.
The templateEditor2.xul file is the basis for a template, or overlay, editor. Ideally, contributors will write overlay templates for multiple human languages, multiple XML languages (SVG, or XHTML, anyone?), and simply multiple presentation templates for any one human-XML combination (translation: alternate texts).
Using parallel MathML markup, we can have one content MathML section cross-referenced to as many presentation MathML (or other markup languages) fragments as you desire (for your language and preferred wordage).
That’s the concept. Implementation is taking a bit longer, and I’ll probably have this file available on abacus.mozdev.org with documentation within two weeks. Please do play with it; it’s offered under the Mozilla tri-license (MPL/GPL/LGPL) scheme. I just didn’t put that in the files yet.
Warning: This may not work yet in your Mozilla. It depends on a patch which fixes XUL DOM’s insertBefore and replaceChild methods (which are definitely broken)

Speak now or forever hold your piece (of code)…

The Open Source Convention has just put out a call for speakers at its 2004 Portland, Oregon event. As my parents live right across the Columbia River in Vancouver, WA, I’m going to be there.
For some time I’ve been working solo on a project to edit MathML in Mozilla, using an XUL interface. There’s nothing released yet, but the (empty) site is at abacus.mozdev.org .
Basically I’m seeking advice on whether I should set up a session to talk about this project. My inclination is “yes”, because MathML editing in Mozilla is something that would benefit a lot of technical people. Daniel Glazman (formerly of Netscape, and lead engineer for Nvu.org) has called the concept a “killer app”.
I’d like your opinions as well. Is it worthwhile?

Turned 26 today… ruminations on me and tech

When I first discovered web design, HTML didn’t fascinate me nearly as much as JavaScript did. It was a language I could play with, and do some pretty neat things with. I managed to come up with several extensions to what JS would allow: a Basket to carry values and objects between windows and documents, a BigDecimal library for calculations with as many digits as you damn well please, even most recently a little assert() function. I’ve written articles on JavaScript several times, and even a big 1100 page book specifically on JavaScript. I’m still the author of probably the only article on the web focusing on JavaScript strict warnings, and I was once the moderator of a forum on JavaScript — a job I walked away from because it just got too big about the same old stuff.
Aside from the assert() function, I haven’t really written anything new in JavaScript in a very long time.
Oh, I’ve been focusing on Mozilla-based technologies more and more — on stuff that isn’t supposed to run in a web page. On XUL and XBL. On specific components within Mozilla that happen to be useful to whatever subject I’m thinking about or developing. But largely I feel my efforts have hit dead ends.
When it comes to JavaScript, I’ve really lost my drive to innovate. With that loss of drive has really come a loss of interest in almost anything that is directly about JavaScript in the traditional forms. I stopped participating entirely in the Javascript help forums I used to moderate. Maybe I’ll drop in on an IRC channel on FreeNode (I think it’s FreeNode), #javascript, and lend a hand there, but that’s about it.
Or maybe it’s not the drive to innovate so much as it is the drive to learn and to teach. I’ve got so much to learn about the guts of Mozilla, particularly C++ (which I’m slowly gaining the ability to read and write), that JS, a language I used to love and now just use, that making new tools in JS, writing new articles to show people about JS, has pretty much lost all appeal to me.
It’s useful of course when I’m designing a website and the customer wants an effect a certain way. Beyond that… there’s Mozilla’s user interface. Other than that… damned if I know what I’m going to do with the JavaScript knowledge I’ve gathered.
I’ve been thinking for months about designing a gridded textbox set, where JS does the tabbing from one field to another for you automatically, for data entry. Why haven’t I done it? I can’t convince myself that anyone would find it useful.
I’ve been working on a MathML editor in XUL. Recently I had to scrap one approach I was using that relied heavily (too heavily, as it turned out) on XBL. I’m reorganizing, but I promised Daniel Glazman that I’d have something ready by early December for his Nvu project. That has not happened.
And of course there’s DOM Inspector. Once again, I respect Christopher Aillon a hell of a lot; I just wish there were more of him, and that he didn’t have such a massive load himself to deal with. 🙂
Okay, I admit, I’m going through some self-doubt caused partially by too many projects I want to help out in, too little time to work on them, and no money to really support me while I do it. I’m on a vacation now; you’d think it would clear my head. It’s only making me restless.
Even fixing simple XUL bugs in Mozilla — and there are a couple where code I have personally come up with is available and easy to modify to fix these bugs — isn’t appealing to me right now.
There’s other stuff that I’m working on that doesn’t involve technology so much (read: amateur fiction), which is at a roadblock as well, so that outlet is closed too.
But to sum it all up: I haven’t got the foggiest idea what the hell I’m supposed to do when I’m on, or when I’m not on, a break.
Am I burned out? Again?

The new Carquinez Bridge

“What a magnificent bridge,” Gov. Gray Davis of California said about the Alfred Zampa Memorial Bridge this past Saturday.
And what a magnificent commute Tuesday morning, even for people who didn’t cross it.
Vallejo Times Herald article
San Francisco Chronicle article
I was going to work in Benicia, which involves crossing under I-80 to go onto Curtola Parkway (which becomes I-780) . It took twenty minutes to navigate what usually takes five, max. Some people were stuck in that mess for hours. One lane open for four hours of traffic, and one of the three lanes closed for another two hours. Oops.
It’s like building a hammer, selling it to the customer, and telling him, “Oh, we’ll replace that macaroni head with a metal one before you need to use it.”
Apparently, they now have all lanes on the bridge open, but it still is not a pleasant memory.
What kind of tribute to a working man is it to build a bridge named after him… that doesn’t work?
“What a magnificent bridge.”

Document Object Model Utility Widgets

Test page with source code
Mozilla’s XUL widgets are great; I love them to death. But for another application I’m developing,
where it’s important to see the structure of a node, and to keep several nodes identical after mutations, XUL just doesn’t have those capabilities. (It wasn’t designed to. Not mozilla.org’s fault.)
So, over the last few days, I’ve come up with the following test page, complete with four new DOM-related widgets and one (independent) function which should help me keep my XUL code in working order.
The new independent function I filed an enhancement bug for adding to Mozilla. It’s a JavaScript-based assert() function, probably not quite in line with how other assert() macros work… but it’s a start.
All this code is under the MPL tri-license, so please do offer feedback, particularly improvements!
UPDATE: Added a new widget which I hope to propose for the Mozilla suite, <xul:menuDeck/>. It selects an entry out of a deck based on a corresponding menuitem being selected.

Patch Maker love

I have a lot of respect for Gervase Markham’s Patch Maker, so much that I really can’t imagine hacking Mozilla without it. Sure, there’s a few weak spots in it — I use timeless’s cvsdo and cvsu Perl scripts for actually adding files to my local CVS tree.
One of the reasons I love Patch Maker so much is the fact that you can do all your important stuff in one command line — call up files, list the files in a patch you’re working on, back the patch out or put it back in, add a file to the patch, diff, etc. Well, almost. If you want to rebuild a certain directory, you have had to change to the directory, do a “gmake -f Makefile” from there, and then change back out to the /mozilla directory.
Not much fun. Until I put a little Perl code together to automate that process for me too. Gerv had reserved a “pmmake()” subroutine in his Patch Maker script, but never implemented it. With a little creative design work to find the right Makefile files to use (once!), I actually managed to get it working. Not bad, I think, when I only touch Perl code once every six months…
I hope Gerv applies the patch and releases a new sub-version of Patch Maker. pmmake() is so useful right off the bat that I’ve found another reason to love Patch Maker. You want me to hack the lizard without it? You must be joking.

OSCON 2004 in Portland, OR

Looks like I get to go home again!
The O’Reilly Open Source Convention, my e-mail inbox informs me, will be held at the Portland Marriott in the week of July 25. Which makes me just peachy.
I’ve been thinking for a few days about trying to organize another Dev Day (like the one we had Nov 9 2001). The biggest question I have is “Where?”
But could we possibly set up a day in one of the Open Source Convention tracks for a Mozilla Technologies discussion? Or, if we had enough speakers, set up our own track at OSCON?
Sure, I’m ambitious. But if anyone out there is interested in speaking at OSCON about Mozilla and Mozilla-based technologies, please, let me know in replies to this entry. Given enough speakers, I can probably get OSCON to help us out. (Plus, speakers in past years have usually gotten free passes to the whole shebang of talks — and I want to speak on DOM Inspector…)

moznet needs a #thinktank

What with Mozilla 1.5 beta about to come out, I think it might be a good idea to have a channel on moznet specifically for “Think Tank” discussions. The concept is simple: a place where interested parties can discuss new ideas for Mozilla-based technologies.
To that end, I’ve committed to opening a #thinktank channel on Chatzilla when I use Chatzilla. Might be useful if for nothing else as a place to bounce around ideas which aren’t ready for discussion on #mozilla (which should remain oriented towards bug fixing and hacking the Lizard directly and immediately). #thinktank would be oriented more towards the long-term than the short-term.

Alex Vincent's ramblings about Mozilla technology, authoring, and whatever he feels like.