It's in need of some slight attention right now. The main problem is that it always prefers munger entries that were enumerated first, which equates to added first in Spidermonkey (Mozilla's JS Engine).
I filed the bug on it a while ago now, but it recently came to my attention that Wikipedia actually had a script that broke stuff because of it. I've corrected the script with version 1.2 so it doesn't completely break normal links, but the real bug still stands.
Filtering stuff is one of those things everyone wants to do, no-one wants to write the code, and even fewer debug it when it breaks. Luckly, this doesn't stop some intrepid people from adding message filtering to ChatZilla.
Of course, the killer questions are:
what to filter with, and
what to do when a filter matches?
The first question is relatively easy, we only have a limited number of things known about a message anyway.
Actual message text, of course
The type of message (PRIVMSG, NOTICE, JOIN, etc.)
Source (e.g. the user object)
Destination (e.g. the channel object)
Handler source. This one is the fun one - it is where the message was displayed 'from', e.g. what code handled it. It may sound useless, except that it will be the default destination if no filters match, and will mean messages for a particular channel will appear on that channel (at least by default!).
That was easy. So what about the actions? They are more fun, as this is where the real flexibility will lie in the system. What I see being included:
display on source view
display on destination view
display on handler view
display on handler's parent view
set message priority (superfluous, activity, attention)
I will be off down to Cov for the entire week, to generally socialise and stuff. Since multiple companies are sucking heavily with regards to something as simple as getting a PSU to me, the computer I am taking may or may not actually have a PSU in it when I take it. I'm willing to bet it wont. The upshot of this is that I may have significantly limited access to anything Internet-like for a few days, but damn well better be on-line by Wednesday.
Since I wont be taking my laptop, twpol.dyndns.org will stay up and fully functioning (bearing with issues like ADSL going pop), and all the usual contact methods will work as good as they ever do.
Note: It seems warwickcompsoc.co.uk has died as of 12:22AM UK BST, suspected to be heatstroke. That wont be back until last morning Monday I suspect.
I have a mostly working line marker! It's not perfect (when it appears, it doesn't scroll the line into view, meaning it is really hard to tell when it is occuring to the unfocused view), but it works for the most part. Still got some issues with scrollDown and force to sort out...
Everything: you use them almost all the time when using the mouse, and pretty often when using the keyboard - though it varies depending on the app.
ChatZilla's menus have been evolving over time since they first appeared, probably at least 5 years ago now, and are a in a bit of a mess. As part of fixing this, I've drawn up the current menus in the Mozilla Wiki. If anyone wants to move stuff around, into the "right" place, and add notes, they're welcome to, after all, it's a Wiki.
Begining build of ChatZilla 0.9.68.6... WARNING: output XPI will be overwritten. Checking XPI structure..... done Checking JAR structure.. done Updating Firefox Extension files..... done Updating Mozilla Extension files.... done Constructing JAR package..C:\Program Files (x86)\Cygwin\bin\perl.exe (3972): *** recreate_mmaps_after_fork_failed ERROR (0) Cannot determine cygwin mount points. Exiting. 3 [main] perl 3972 fixup_mmaps_after_fork: WARNING: VirtualProtectEx to return to previous state in parent failed for MAP_PRIVATE address 0x1ED0000, Win32 error 87 538 [main] perl 3972 fixup_mmaps_after_fork: WARNING: VirtualProtect to copy protection to child failed forMAP_PRIVATE address 0x1ED0000, Win32 error 487 680 [main] perl 3972 fixup_mmaps_after_fork: ReadProcessMemory (2nd try) failed for MAP_PRIVATE address 0x1ED0000, Win32 error 487 C:\Program Files (x86)\Cygwin\bin\perl.exe (3972): *** recreate_mmaps_after_fork_failed 6 [main] perl 2916 fork_parent: child 3972 died waiting for dll loading
And thus ended my Cygwin Perl installation. No matter of rebaseall-ing or complete Cygwin reinstalls could fix it, and I don't even understand precicely what the error is.
So a short while later, I had myself an ActiveState ActivePerl install, perl-cygwin.sh (a wrapper I wrote to use ActivePerl in places expecting Cygwin Perl), and some tweaks to makexpi.sh to let me specify the Perl engine (save me doing path & symlink hacks). And thus it did build! Yay!
So much for early-June. Well, the tree is still frozen, which doesn't help at all. Plus reviews are slower than expected. We're also not going to get 0.9.69 out any time soon at all - the next release will be 0.9.68.6, hopefully not too far away now.
We are, however, making slow but steady inroads into the bug list, and have a few people outside the 'core' (Robert Ginda, Samuel Sieb and myself) who are doing patches and generally helping a lot. It sounds like we're going to get a better (ish) reconnect system shortly, too.
The next ChatZilla release will be called 0.9.69, mostly due to the excess of changes that have occurred on trunk since the last release. This will be the 0.9.68.5 codebase merged to trunk, plus some extra compatibility updates; this means all the trunk changes since then will be included - and there are a lot of them!
I suppose I probably should mention that ChatZilla 0.9.69 has been released. Woo.
We're currently working through a couple of big issues, but the release is great. The main problem anyone is likely to encounter is bug 319066, which should only occur if you select the top user in the userlist, and then switch tabs.
We can also estimate that there are approximately 1100 new or updated ChatZilla users a week (calculation: sum up new installs [the numbers on the pages linked, 40], divide by the number of days , multiply by 700 [1% and we want per-week]).
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.
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.
Some people know about the ChatZilla Release Console, a slightly unstable and very dynamic page which displays the bugs planned for the next ChatZilla release or two (as well as an archive of bugs fixed in older versions). It's been around a while, and works in IE 7 and Firefox 2, but it is pretty heavy on the dynamics, and some people have had it completely hang Firefox on occasion.
Otherwise, due to a bug, you will need to download the master archive and extract it in to a new subfolder of the "scripts" folder. This can be found inside the path shown by the command "/pref profilePath".
[INFO] Preference “profilePath” is “C:\Users\James\AppData\Roaming\Mozilla\Firefox\Profiles\secret.dev-edition-default\chatzilla”.
=-= Nickname has changed the topic to “ChatZilla topic diff test” =-= Nickname has changed the topic to “ChatZilla diff test” =-= Nickname deleted "topic ". =-= Nickname has changed the topic to “ChatZilla diff testing!” =-= Nickname added "ing!". =-= Nickname has changed the topic to “ChatZilla topic diffing” =-= Nickname added "topic ", deleted " test", deleted "!".