Silver's Simple Site - Weblog - 2007

This is just an informational post to say that I have created my own fork of Venkman so that I can actually get some damn work done on it. More information will follow; for now you may rant and rave in ignorance.

Since the fork just over a week ago, the following issues have been fixed:

• Bug 270298 - Fix profiler to show proper ranges.
• Bug 295275 - Fix long-standing bug with floating views going blank. Woo.
• Bug 298736 - Don't get button-related code execution when pausing.
• Sync some changes from ChatZilla to Venkman. Source views work better after this.
• Bug 356267 - Fix componentPath to work with toolkit's array of paths. Causes extensions' components to count, for example.
• Final part of script filtering - preserving chrome, search and recent exclusions; everything works as expected now.
• Bug 213494 - Sort properties using numeric and non-numeric blocks.
• Prevent default operations when using -venkman.

More things will be fixed over the coming weeks; any suggestions for which bugs in Bugzilla are causing the most problems are welcome.

Now for the important bit - how to access all this goodness:

cvs -d :pserver:anonymous@twpol.dyndns.org:/cvsroot/extensions checkout venkman

Note that, at least for the time being, the fork will continue to have the same extension ID and name as the original and I will not be releasing any XPIs generated from this code (this is very likely to change).

Now that it has been officially stated that XULRunner is dead, it is time for a ChatZilla Roadmap Change™.

The original XULRunner and ChatZilla plan was to wait until the 1.9 version of XULRunner was officially distributed - 1.8 was never going to have the necessary shared UI or support - and then produce a ChatZilla package that works on it. Ideally, we would use the same XPI as for Firefox, SeaMonkey, etc. installs, although there were/are still some pretty critical hurdles to overcome for that to work. Even if it was a separate XPI, it would be a normally-size ChatZilla XPI, and could be on Firefox Add-ons.

So much for that.

After getting over the initial "WTF?" reaction, we need to decide on the way forward for ChatZilla on XULRunner. Thanks to tH's wonderful ChatZilla on XULRunner page (which include mozilla.org built nightlies from the appropriate dates), we do actually have a measurable percentage of our user base running this configuration. A small percentage, but not zero.

• Do we build XULRunner ourselves? This would require a lot of effort on our part, and really should be shared with other projects if possible.
• Do we only make available our ChatZilla package, and tell users to find their own XULRunner (or link to someone else who is making them)?
• Do we give up trying to support XULRunner entirely?

Right now, I don't know, but the last option is looking disappointingly good.

I'm sure browser plugins come with their own little Quantum Failure Generators or something. I've spent most of today trying to narrow down certain sizing issues with the Windows Media Player plugin across various OS versions and browsers. It was not (and still isn't) fun.

At one point, even Virtual PC 2007 itself crashed.

Then, starting openSUSE 10.2, it decided that it needed to fsck each and every partition just because it hadn't done it for a while. This would have been fine, except that it blocks the boot process for upwards of an hour with no indications on the graphical boot screen.

Now, I'm about to go install some beta software as part of a private beta test program; this can't possibly go wrong, can it?

ChatZilla users have for a while wanted to get a notification on all messages, but we've never considered it important enough to warrant fixing individually, instead opting to recommended some workarounds:

• Add all vowels/letters to the Stalk List, thus triggering the normal stalk matching on (almost) every message.
• Write a simple script, but never providing one ourselves.
• Wait for the new message filtering which will be able to do it, among many other variations.

Today, another user asked for this feature, and I caved in and wrote a script to do it. To install the script:

1. Find the scripts folder. You can use either /pref profilePath or /pref initialScripts since the latter defaults to the "scripts" subdirectory of the former. You want the "scripts" subdirectory, if that wasn't obvious.
2. Create a new directory for this script. My suggested name is "message-notify", just to match the script's ID, but ChatZilla doesn't care.
3. Save the script itself into the new directory, making sure to name it "init.js".
4. Reload all scripts with "/eval processStartupScripts()". This will reload all the scripts found in the subdirectories of the "scripts" directory - including the new one.

The following message categories trigger the script, but only when the window is inactive (nothing happens if the window is active):

• channel:privmsg
• channel:action
• channel:notice
• channel:join
• channel:part
• channel:quit
• channel:kick

The script has two preferences:

• sound - specifies what sound to play when a message arrives. Defaults to "beep", and can accept the same things as the standard ChatZilla sound preferences (namely, a file: URL, "beep" or "none").
• attention - specifies whether to grab the user's attention, which usually means flashing the window but can vary by platform. Defaults to "true".

Enjoy.

It's that time of year again. I will be away from Monday (25th) to Friday (29th), enjoying the annual mega LAN.

1. E-mail people at 6PM saying the server will be offline as of 10AM the next day.
2. The next day, find out that the new server doesn't want to work with the disks from the old server.
3. Overwrite the partition table on one of the disks.
4. Spend hours backing up the data and rewriting the partition table by hand.
5. The next day, copy data and install new server into limited-access server room.
6. While remotely migrating setup, remove /etc/passwd file (thus preventing all remote access).
7. Wait 3 days to gain physical access to the machine.
8. Slowly start setting up everything.
9. Have users find out that some of the services are now running different software and didn't have their data migrated over.

Things which could have been better:

• Advanced notice of migration. Server migration is never simple, advertising it the night before is seriously inadequate for most people.
• Notice of which services, if any, will not be migrated exactly as-is, and how the decision was made.
• Setting up existing services on the new server prior to the swap.

Even now, the server still isn't running all services correctly, but hopefully it will be soon. I look forward to receiving mail via the new server, 4 days after it was supposed to be all working. ;-)

General Language and Keyboard Shortcuts

These can be changed from Control Panel, in Regional and Language Options, Keyboard and Languages tab, "Change keyboards...", Advanced Key Settings tab. Alternatively, right-click the Language Bar and select "Settings...".

Japanese IME Shortcuts (summary)

These can be changed from the Japanese IME itself, which can be accessed from the Language Bar (right-click and select "Settings...", then select the IME and click "Properties..."). On the Editing tab, there is a drop-down of key templates and the option to edit. The above keys are all for the default key template ("Microsoft IME").

For many years, the code behind the Mozilla Error Lookup has been unable to correctly include the LDAP and CMS error codes, as the C++ definitions used the IDL constants and the script is just not smart enough for that.

It is now.

That means that all the error code definitions it can find are now correct and can be found from their numeric forms. Enjoy.

I am currently in the progress of implementing the necessary features and components in my weblog software to allow the use of a standalone client to post entries (and ultimately edit, as well). As I'm already beta testing a bunch of other Live tools, I thought I'd start with Windows Live Writer.

The current beta version supports:

• WordPress.com
• Blogger
• TypePad
• LiveJournal
• Movable Type
• WordPress (inc. 2.2+)
• Community Server
• dasBlog
• Radio Userland

Additionally, it supports two raw APIs on anything that implements them:

• Metaweblog API
• Movable Type API

Not bad. So, I've chosen the Movable Type API for mine, but I'm jumping ahead - there's something else, something really cool, that I should mention.

Really Simple Discovery, RSD, is a method by which a tool can identify information about a page and its supported editing schemes. Including a link in the main weblog page with rel="EditURI" to point to the RSD file (which is XML), and that indicates which editing APIs are supported and their respective URIs.

Windows Live Writer checks for and uses the RSD information, which results in a 3-entry configuration: weblog URL, username and password. It doesn't get much simpler than that.

Still to come: the Movable Type API, Blogger, categories and more.

I find Microsoft Windows Vista Media Center is great in so many ways, but nothing's perfect (more's the pity).

One thing which has been irritating me for a while is how it was using the "shrink-to-fit" method of sizing local video playback instead of "expand-to-fit". This results in any wide-screen videos losing the left and right edges, as I only have a 4:3 monitor (shame on me). I believe it'd be causing equal problems with non-wide-screen videos if I had a wide-screen monitor, though.

Until a few days ago, I'd been using ffdshow's capable suite of options to force output into 4:3 (while preserving the aspect ratio, i.e. adding evil black bars). This really eats CPU, even on the fastest resize mode, increasing usage by approximately 30%, which was actually causing my AMD64 3200+ (2.0GHz) to run out of cycles on some videos.

What I found a few days ago, though, was the real solution: time to start the Registry Editor, folks. Locate the following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\VideoSettings

Under this key there are a large set of options, most of which you don't want to touch. In this case, however, one particular one is crucial - ZoomMode_Video. Set that to "0". Done.

Footnote: There are 3 other ZoomMode_ options (ATSC, DVD, TV) and all 3 were already set to "0" here. ZoomMode_Video, however, was set to "1". I'd be very interested to hear how many, if any, other people have any of these ZoomMode_ options not set to "0" and which ones.