DMDircthe intelligent IRC client

In DMDirc 0.5 we introduced a feature described in the release notes as “intelligent tab completion for commands” (introduced in this blog post), which allowed commands to tell the tab completer about the arguments that they’re expecting. In that incarnation, commands can specify a bunch of extra words to add, and can toggle whether the default tab completion targets (nicknames, channel names, command names) are used.

In DMDirc 0.6, we’ve taken this one step further. Commands can now specify exactly what group(s) of targets should be used - so, for example, the first argument of the /ctcp command will now only tab complete to nicknames and channel names (but not command names, as it would have done in DMDirc 0.5).

We’ve also added support for what I call “deferred intelligent tab completion”. This comes in to play with the half-dozen or so commands that take another command as one of their arguments, such as the /alias command, which takes an alias name and then a command to associate with that alias. So, say you want to create an alias to start a timer that will CTCP PING a certain person after five seconds. You type: /ali<tab> ping /tim<tab> 1 5 /ctcp Nickname <tab>. When you hit that final tab, DMDirc suggests eight standard CTCP types (PING, FINGER, VERSION, etc…), even though the CTCP command is in the middle of a much larger command. How’s that for intelligent tab completion?

As far as I’m aware, no other IRC client comes close to the intelligence of DMDirc 0.5’s tab completer, so DMDirc 0.6’s puts us leagues ahead of the competition in that respect. But, as ever, we’re eager to hear any feedback or suggestions that you might have - feel free to leave a comment here, drop by #DMDirc on Quakenet to talk to us, or use the “Send feedback” feature (available in the help menu) of DMDirc 0.5.5.

We have just released version 0.5.5 of DMDirc. This release is an interim release between 0.5.1 and 0.6 to get some important features of 0.6 in use in the stable version.

Some of the main changes include:

• The new launchers which give the client the ability to update itself via the updater
• URL Handler to allow adding support for non-http links (Eg steam://, ftp://)
• Much improved plugin system (Plugins are now stored in jar files rather than loads of .class files)
• Many more, read the changelog for a full list.

The installer for DMDirc 0.5.5 can be downloaded for Windows or Linux.

The latest major change we’ve added to the 0.6 branch is a revamp of the preferences system. The original purpose of the revamp was to shift a large amount of logic out of the UI and into the main client core, so that if/when we have additional user interfaces written, they don’t have to duplicate several hundred lines of code to produce a preferences dialog.

We took this opportunity to move plugin configuration settings into the main preferences dialog. This makes the configuration options for individual plugins much easier to find, and reduces the amount of clutter in the Settings menu somewhat. Here’s a screenshot of the new prefs dialog — you can see the configuration categories for all of the plugins I have installed, as well as the plugin manager itself in its newly integrated state:

We still have some more improvements planned for the preferences dialog in 0.6, including a new component to allow easier editing of duration fields (no more entering times in milliseconds!), and better management of optional colour fields.

In other news, DMDirc 0.5.5’s release is drawing very close. DMDirc 0.5.5 has been the most tested release to date, and we’re working out the last few problems now. You can view the current changelog or the draft release notes if you’re interested in the changes since DMDirc 0.5.1. If you want to try it for yourself, or want to help us test it, you can try an unstable release of DMDirc.

Since DMDirc 0.5.1, the Linux and Windows installers have received several major updates.

Firstly, the Linux installer was overhauled to show all of its messages in GUI dialog boxes where possible (using kdialog under KDE or zenity under gnome). This means that users don’t need to be running the installer from a console to see what went wrong. (The messages are still also relayed to the console). This update is part of the DMDirc 0.5.5 release, which should be available soon.

The next major change is that both the Windows and Linux installers are now capable of installing Java, either by using a JRE bundled with the installer or by downloading one from java.com. This is a major positive step as it means that it is possible for people who don’t have Java (or have an outdated version) to use DMDirc.

This new functionality is in all the nightly installers from December 24th onwards, comments/bug reports etc are welcome here and on the issue tracker.

I’ve just committed changes to DMDirc that allow you to make use of what I call “condition trees” in actions. These basically allow you to specify how conditions should be evaluated. In DMDirc 0.5.1 (and earlier), all action conditions had to be true in order for the action to be executed. Condition trees allow you to use any combination of AND, OR, NOT and brackets to alter this behaviour.

An example condition tree looks like this: (0&(1|2)&!(1&2)). The numbers refer to the outcome of the conditions (in this case my action has three conditions, which get numbered 0, 1 and 2), and &, |, ! and the brackets have their expected meanings. If you’re not too fluent in boolean logic, the condition tree translates roughly as “condition 0 is true, and exactly one of conditions 1 and 2 are true”, or “condition 0 and (condition 1 XOR condition 2)” if you want.

At a basic level, condition trees allow you to reduce the number of actions you have (for example: if you want to do something whenever someone mentions your nickname OR when someone starts a message with “!hello”, in DMDirc 0.5.1 and below you need two actions with duplicate trigger/response/format settings; in DMDirc 0.6 you will only need one action with a condition tree set). Beyond that, condition trees allow a much closer approximation to ‘if’ statements in scripting languages, thus enabling extremely complex conditionals without the overhead of a scripting language or the learning curve of one.

(more…)