E-mail addresses now required (and hello “Alex Santa”)

I’ve changed the configuration on my weblog to require e-mail addresses from all commenters. Rest assured, I won’t disclose them; I just want at least some idea of who’s talking to me, so I can respond.

More to the point, I’ve been getting another new surge of blogspam lately, and so I did a few WHOIS searches on several of the domain names that keep popping up. One “Alex Santa” of Moscou, RU keeps coming up.

Mr. Santa, I am writing this to you now: either you or someone you are paying has been blogspamming me (and probably most of my feedhouse/planet companions) for a very long time now. However, I thought you might have caught on by now that it’s not working over here: every one of these blogspam for over two years has not seen the light of day on my weblog.

Ultimately, since the source of funding for these blogspam is coming from you, you may find yourself the target of a lawsuit. Not from me alone (I don’t have that much money), but sooner or later you’re really going to tick someone off. We’re spending too much time cleaning up after you and those you pay to advertise your worthless link sites.

The base for XUL Widgets

I’ve been thinking the last few months about a change for XUL Widgets, and now that Firefox 2.0 Beta 1 is available, I need some advice from the community.

XUL Widgets, for those of you who haven’t followed it, is a MozDev project to extend the standard mozilla.org toolkit of XBL-based widgets. Other projects are invited to adopt XUL Widgets as an extension and use the extended toolkit in their own applications. I’ve been updating it from time to time with new features (or fixing bugs in the update code), but now I have to decide which version of mozilla.org’s toolkit XUL Widgets should support.

Currently, there are three versions I’m concerned about: 1.8.0.x branch (Firefox 1.5), 1.8.x branch (Firefox 2.0), and trunk (Firefox 3.0). A few of the changes I’ve made for XUL Widgets have landed in the 1.8.x branch, and a few more in the trunk. So my own unreviewed changes may conflict or degrade the expected results in these versions. On top of that, there are new capabilities in trunk (and to a lesser extent, 1.8.x branch) that weren’t available in 1.8.0.x.

To my knowledge, I’m the only one actiovely using the XUL Widgets extension. If I am truly the only one interested in using it, then there’s no reason for me not to switch its base to trunk. My usage of XUL Widgets is for Verbosio, and that cannot run on the 1.8.0.x or 1.8.x branches.

I’d like your feedback, especially if you use XUL Widgets. Which version of the toolkit should I base my extensions on?

UPDATE: Case in point: Trunk code just now received an active spinbuttons widget, which my integercontrol could easily depend on.

A proposed Verbosio logo

Verbosio logo (draft)

I decided to try my hand at a bit of artwork tonight. I’d been wondering what sort of logo I’d use for Verbosio, and this came to mind – another reference to XML, and to writing.

Opinions? Has this sort of logo been used by someone else before? I’d hate to infringe on someone’s trademark…

UPDATE: The general consensus is that it is unique (yay!), but a bit basic. To me, that’s okay for now. I’ll gladly accept contributions of new SVG markup (preferred) or PNG graphics that do the logo in a better way. Just please don’t hold any license on it; I’m not sure what licensing to hold the logo under for the project anyway, considering Verbosio is open-source, low-budget and likely to stay that way…

Accessible extensions?

There’s been a thought rattling around in my brain for a while, but when my hand started hurting a bit today, I thought a bit more.

Many of the Firefox extensions I use don’t have keyboard shortcuts. Or, for that matter, menuitems inserted by overlay into the main toolbar.

I’m not intending to point fingers (I’m guilty of not considering a11y with tinderstatus), but there are some popular extensions out there that could really use some accessibility love. Including several that I use on a daily (and in one case, hourly or even more frequently 😉 ) basis.

On the other hand, there is the danger of two or more extensions picking the same key combination to do something. I am acutely aware of that problem; I face the same sort of issue at a higher level of magnitude with Verbosio. We might need some kind of functionality through Firefox’s Extension Manager to override assigned alternate UI’s to their core functions. (What to do for extensions missing UI I haven’t figured out yet.)

Thoughts? I’d be willing to design & patch for this, but I want some community feedback (and if I do patch, a general assurance that it will get fast reviews). Is this worth doing? If so, how would you want it to work?

XUL Widgets, version 0.3.0 1 2

To quote Jamie Hyneman, “Whoops!”

In posting the 0.2.* series of XUL Widgets XPI’s, I listed incorrect information in the install.rdf and update.rdf files. This mandates posting a new XUL Widgets 0.3.0 XPI & XULRunner series.

No new functionality, but you will find XULRunner 0.2 will not receive any future updates. So please uninstall it before installing version 0.3. XUL Widgets version 0.3 should be available in 24 hours or less.

UPDATE: Another well-formedness error bit me, install.rdf. 0.3.1 released now.

UPDATE 2 : Note to self: chrome.manifest is useful. 0.3.2 released.

A marathon coding session

There are so many things wrong with Verbosio in its current state that it’s hard to keep the faith, and keep going. A number of large issues have been bubbling around, the biggest one being that I can’t support WYSIWYG editing. But that’s a discussion for another day.

Because Verbosio is intended as a complete application, involving a combination of chrome, content, and extensions, getting a proper development environment is notably a struggle. For example, I simply forget how to recompile IDL files after I’ve made a change to them. IDL’s are actually pretty important in Verbosio, so that barrier alone to development is tough.

On top of that, I frequently make changes to Verbosio code, and forget to move it back to my Verbosio repository. I’ve probably got six or seven complete copies of Verbosio in various states of disrepair, and so by not using the advantages of CVS revision tracking (SVN would be better, but mozdev doesn’t have that yet), I have allowed myself to lose pieces of code in development… which is even worse than outdated IDL’s.

So on Friday evening, wanting to get myself organized, I grabbed Mozilla Sunbird 0.3a2 (I’m a developer – alphas only frighten me a little), and started writing down some of the unfinished business I have with regard to Verbosio and mozilla.org bugs. It turned out to be a big list… and the first thing on it was to simplify the development process between repository and objdir’s. In other words, time to write some Perl and shell script code.

Now, I’m not all that great at Perl. But over the last year at ManyOne Networks, I’ve been exposed to more than a little of it. So with a handy Sams Teach Yourself Perl in 24 Hours guide, a few script subroutines borrowed from work, and an unhealthy bit of trial and error… I got a basic make-project.pl script written to handle exporting repo code into objdir code, and set up for the reverse.

I could have written it as a Makefile, I suppose… but Perl seemed to have more of the capability I needed. The Makefile will of course call on the Perl script… later.

Just to write this one script has literally taken me about 18 hours in pretty much one straight shot (one break for food, and another break for Saturday night anime). Along the way, I learned a few things:

  • XPIDL generates .xpt files for one IDL file. To get more than one IDL into a .xpt, you have to use xpt_link. I think it was shaver who told me that…
  • Mozilla’s cygwin-wrapper doesn’t like /tmp. Imagine that. I can’t really blame them, though.
  • I am woefully inexperienced with shell scripting.
  • I really should learn more about Perl, in particular Perldoc.
  • I should also find or write a common assert() & design-by-contract functionality for Perl. die()’s okay, but not great. I like debugging structures in any programming or scripting language. (Maybe I can ask Damian Conway nicely for it. If he can handle Klingon with Perl…)
  • Okay, I didn’t so much “learn” as “already knew” this one: when one doesn’t eat for over 15 hours, including sleep, a mental numbness begins… I skipped breakfast and lunch, and my dinner was at about a quarter to nine PM here. I last ate at about 1:30 am. I actually wanted to leave about 5 PM, but it took me another three hours to get my code to a stable-enough setting (i.e. no more “Just one more change to get this working”) where I could walk away.

I woke up Saturday morning about 8:30 AM. It’s now 3:15 AM Sunday. Marathon coding sessions for me are relatively rare, but they do happen. Kinda like when I was writing my book for Sams Publishing – though I’m not planning on doing 40 hours without sleep like I did five years ago. I’m going to bed now.

Incidentally, I’ve been spending a bit of time lately writing patches for mozilla.org trunk code, just to support features that a editor like Verbosio should have. Patches that really make Verbosio moderately useful.

I’ll take suggestions on CPAN modules for design-by-contract…

MathML 3.0: Work is beginning

I realize this announcement might be premature, but it might be of some interest to people (including the WHATWG contributors, some of whom are violently opposed to MathML in its current form). W3C Launches Math Working Group for MathML 3.0

I think this is excellent news: a chance for us to fix some of the issues with MathML. It’s too bad I’m not working for a W3C member, and have no corporate justification to be involved… just a personal obsession with mathematics and computers that’s lasted all my life… 🙂

An expensive lesson

About a month ago, I bought a bicycle and trailer. I loved the pair – they went together like peanut butter and jelly. I didn’t use the trailer much – I bought it to move my laundry from home to the laundromat and back. So often I’d leave it at my place while I took the bike to work.

Last Thursday, that trailer was stolen from my motel in Santa Cruz, CA.

It cost me $150.00. I’m really bummed out about it, because it was such a useful tool. The lesson for me is to keep little things like that locked up.

To the thief: I don’t know who you are, or why you took it, but I hope you would return it. I’ve notified the Santa Cruz Police Department, and I’ve notified the bike shop that it came from (they say it’s the only one they’ve ever sold, and that no other bike shop in Santa Cruz carries that line of trailers). I’ve even put in a prayer on your behalf. It was a nice little black trailer, and I do need it. If you have a heart (and you still have the trailer or can get it back), I’d really appreciate having it back, even anonymously – but preferably in good working order.

Also, for those of you familiar with the Bible: I do forgive, but I do press charges if it’s not returned by the thief.

XUL Widgets now supports XULRunner

XUL Widgets installation instructions

By this, I mean XUL Widgets now packages its chrome to be easily dropped into an existing XULRunner application. It’s a beginning step (possibly incorrect, but simple) for building a chrome package for a larger app. I’ll be porting the code used to make this chrome package over to jslib and xpistubs shortly.

UPDATE: JSLib and xpistubs now have code checked in to support XULRunner as well! No new packages generated for jslib yet; I leave that up to the mozdev team.

If you have a xpistubs-based project, drop me a line. I may be able to help you apply the patch to your own project.

ManyOne: Anyone out there with plug-in development experience?

I’ve had a request from my supervisor to see who might be able to assist with plug-in development for Mozilla-based browsers. This specific case is about “Celestia”.

Right now, this is just exploratory, no solid commitments as yet. We have a small budget for the right person to research what we’d need to do to implement Celestia as a plug-in for Firefox.

Please reply by comment to this blog – no resumes just yet – if you’re able to help. E-mail addresses will be required, as we will probably be sending you a little more detail by e-mail later. If you don’t want the e-mail address posted publicly, please note so in your comment; I read all the comments and will pass the e-mails on to my supervisor.

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