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.
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).
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.
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:
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.
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.
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)
Normal Mode (not in the middle of entering a word/phrase)
<Control> + <Caps Lock>
Switch to Hiragana input
<Alt> + <Caps Lock>
Switch to full-width Katakana input
<Shift> + <Caps Lock>
Toggle half-width alphanumeric (English) input and Hiragana input
<Alt> + <`>
<Control> + <Shift> + <Caps Lock>
Toggle kana and romanji input
<Shift> + <Space>
Enter half-width alphanumeric (English) space
Conversion Mode (when entering word/phrase via IME)
<Shift> + <Left>
Use less characters for conversion
<Shift> + <Right>
Use more characters for conversion
Convert to Hiragana
Each of these will flip through a number of possibilities on each press.
Convert to Katakana
Convert to half-width Katakana
Convert to alphanumeric
Convert to half-width alphanumeric (English)
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 (inc. 2.2+)
Additionally, it supports two raw APIs on anything that implements them:
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.
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:
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.