<Person> Hey, you, why don't you join #channel2 (and maybe #channel3)?

DMDirc now applies the same intelligent linking algorithms we use for URLs to channel names, so we can intelligently figure out what was probably meant to be part of the channel name, and what was punctuation following it. With our new “stylechannels” option enabled, that message will show up as:

<Person> Hey, you, why don't you join #channel2 (and maybe #channel3)?

As you can see, we now correctly realise that the “)” and “?” at the end of #channel3 probably weren’t intended to be part of the channel name. And with stylechannels enabled you’ll be able to see exactly where you’re going to end up before clicking.

But we’re not done yet! What if you’re more of a keyboard aficionado than a mouse lover? You want to use the /join command, but don’t think there’s an easy way to get that channel name that was just mentioned without copying it by hand or resorting to the mouse? Think again – DMDirc now has intelligent tab completion for its /join command. This keeps an eye out for any linked channel names, and suggests any you’re not already in when you hit tab! So after our friendly user suggests two channels to us, we can type:

/join <tab>

And DMDirc will suggest #channel2 and #channel3. What’s more, if you decide you want to join multiple channels, recent upgrades to our tab completer allow the join command to offer useful suggestions if you comma-separate the channels:

/join #help,<tab>

Will offer the suggestions #help,#channel2 and #help,#channel3.

All of these features will be available in DMDirc 0.6.4, which should be out at the start of July. If you can’t wait that long, you can try a nightly build. Think of any more ways we can make DMDirc intelligent? Leave a comment, poke @DMDirc on Twitter, or you can of course join us on IRC.

• 0.1 was released on the 1st of March 2007
• 0.2 quickly followed 5 days later (6th March)
• 0.3 was 1 month, 18 days after that (24th April)
• 0.4 followed after 1 month, 18 days again (11th June)
• 0.5 then came 3 months, 15 days later (26th September)
• 0.5.1 was then released as a bug fix a mere 11 days after that (7th October)

So that was six releases in just over 7 months. We were happy to be doing regular releases as we felt it was more likely to keep users with us as the client evolved quickly. However, this pace soon died down and 3 months, 23 days later (which was at the time the longest we’d gone without a release), with no sign of 0.6 being finished any time soon, we made the decision to release 0.5.5. This was intended as a half-way point between 0.5 and 0.6 to try and keep the releases regular, with the idea that 0.6 would follow in a similar time scale. This was not quite the case, as it took us a further 7 months, 12 days before 0.6 was released!

Shortly before the release of 0.6 we looked at the time between releases, and took the decision to split our workload for 0.7 into 3 separate parts (as described here) in order to try and bring the release time down to a more reasonable time scale. After some time it became obvious from the amount of outstanding issues for 0.6.3 that this again wouldn’t work, as six months in we still had a large number of major features outstanding. We therefore decided once again to split the release further into a set of “milestone” releases — 0.6.3m1 (which we’ve just released), 0.6.3m2 (up next) and then probably 0.6.3 proper. These milestone releases were supposed to be point in time where we thought the client was in a good state that we would finish anything we were working on, tidy up the code and release.

Well, 9 months, 16 days after the release of 0.6 we released the long-awaited version 0.6.3m1. We once again took a hard look at this and have come to the conclusion that this simply isn’t acceptable, despite two attempts at breaking the release down it still took us 9 months to do what essentially boils down to 1/9th of the 0.7 release we had originally planned (assuming that 0.6.6 and 0.7 will also be split into two milestone releases).

So now we are going to introduce yet another change to our release cycle. We are going to continue with 0.6.3, 0.6.6 and 0.7 as separate release targets, but instead tweak how we handle milestone releases. Currently we decide to release a milestone randomly when we feel that the client is stable, instead we are going to try and stick to a reasonably fixed release cycle of 4 months in between releases. Approximately 3 months after the last release we are going to start the process of preparing for a milestone release. This will entail a feature freeze and the bumping of any non-essential issues back to the next milestone. Following this we will finish any currently outstanding issues (or bump them if there is still too much to do), a reasonably quick QA cycle (during which we open up the UNSTABLE updater channel to allow for testing of the upcoming release) and then release after the 4th month and repeat.

So with this new release cycle we hope to go back to our original faster-paced release strategy without losing any of the quality we like in a release, and should be looking at releasing the next milestone on or around the 1st of November, so watch out during October for news of the pending release of 0.6.3m2!

From the start we wanted DMDirc to be an excellent client, and we quickly got it into a usable state (I have logs showing me using it in early May 2007). To help us do this we registered with Google Code, which provided us with a Subversion repository, download hosting and an issue tracker.

In addition to the tools on Google Code we also wrote a service that received error reports from DMDirc clients, and allowed developers to browse them using a web interface. This system never really worked too well; it meant that we in effect had two systems for tracking errors, the automated error system (which was checked manually, and therefore quite infrequently) and the user-facing Google Code issue tracker. The Google Code issue tracker also had quite a few issues of its own [ba-dum-tish] that posed problems for us: we didn’t have much control over it, Google were slow to improve it, and it didn’t allow for dependencies or private issues. The lack of private issues was the reason we felt the need to have two separate systems at the time — automatically reported errors may in some cases contain private information, so we can’t show them publicly.

Sometime just before DMDirc 0.5.5 was released, we decided to start using Mantis as our primary issue tracker. Mantis, whilst not perfect, gave us the control we wanted — it’s written in PHP (which, like Java, we all know very well), and is easy enough to modify. We imported all of our existing issues from Google Code, using a Python script (yay for multi-language proficiency!) to screenscrape the website and build an XML file, and then a PHP script to read the XML file and import the issues into Mantis. With the issues imported, we set about modifying Mantis to better suit our needs.

We (well, Chris and I) had got quite used to using the issue ‘grid view’ offered by Google code, so one of the first things we did when switching to Mantis was implementing our own version of it. We also improved the error reporting backend to raise new Mantis issues (marked as private, of course). Later on, we also enabled SVN integration, which initially meant writing a script to parse e-mails from Google Code (where our SVN repository was still hosted) and passing the information on to Mantis for it to use. After a while, we modified the integration to include links to our Fisheye instance, and also map Subversion users to Mantis users in order to add comments with the appropriate username instead of just ‘SVN user’.

More recently, we’ve improved the Fisheye aspect of the integration dramatically; we now access Fisheye and include its representation of the changes directly in Mantis, allowing you to see a list of affected files and even view diffs of the changes without leaving the issue page. We also parse any stack traces in the issue description, and automatically link relevant lines to the Fisheye view of the specified file and revision, if the information is available. You can see an example of both of these modifications in this issue.

Now, as I mentioned above, we are all heavy IRC users so having to periodically check Mantis for new bugs wasn’t very appealing to us, so we modified it some more so that it communicated with an IRC bot we have which is designed to relay notifications. Mantis tells us everything that happens — new issues, edited issues, property changes on issues — anything that happens there, we instantly know about it.

This setup worked well for us for about 4 months, after which we decided to switch over to using a self-hosted SVN Repository, which opened up even more possibilities. We added post-commit hooks to replace the email-parsing hacks for Mantis support, enabled reporting of commits to IRC, and created a pre-commit hook to make sure that every commit was linked to an issue on Mantis.

Not long after that we discovered and implemented Bamboo into our development process. Bamboo is a Continuous Integration server, which means that every time we commit something to the trunk (or active branches), it will rebuild the project on our server, run our collection of unit tests and then publish and store the results. Bamboo also notifies us via Jabber if you cause a build to fail. Of course this wasn’t quite perfect, and after a short while we discovered a plugin that can execute post-build scripts. One Bash script later and Bamboo was reporting to IRC like everything else. We also, of course, integrated Bamboo with Mantis. If you check this issue again you will see that the results of the build from Bamboo are also reported under the the commit that triggered it.

As mentioned before, we have a collection of unit tests to make sure things work as expected. Every so often we generate Clover reports to show how much code coverage we have, and in the last month we have also discovered and began using the FEST Swing library to allow us to start unit testing the DMDirc GUI.

So as you can see, what we have now is a very tightly integrated system to help ensure that DMDirc is a quality product. Everything reports to IRC so we know as soon as things happen, our issue tracker is almost omnipotent in that it can tell nearly everything about an issue from being raised to being fixed, and to top it all off, we have Nagios running and monitoring it all for us (and of course, this reports to IRC also!)

Of course this setup wouldn’t be possible if it wasn’t for a few choice products provided for free — Mantis, Fisheye, Bamboo, Clover and many others. We would like to thank the developers of these products for helping us make DMDirc great.

Why “the intelligent IRC client”? Well, we think DMDirc’s built-in ‘intelligence’ is the most significant aspect that sets it apart from other clients. We’ve yet to see another IRC client that has tab-completion anywhere near the quality of DMDirc’s, or that parses links as well as we do. We have more enhancements coming for both of these areas, too, as well as plans to make other DMDirc features more ‘intelligent’.

While the two areas mentioned above may not seem ground-shatteringly important, they improve the usability of the client quite a lot. The difference they make is most noticeable when you use another IRC client, and find that you can no longer tab-complete command names, or that a link in the topic includes a closing quotation mark when you click on it, which means you have to do something extra (open the manual to look up the command name, manually copy the URL or modify it in the browser, etc) in order to do/find out what you want, instead of it just working.

DMDirc 0.6 (coming soon; we’re going to be pushing out an alpha version this weekend) features a lot of enhancements to the ‘intelligent’ aspects of DMDirc, some of which we’ve discussed previously. But, as always, we’d love to hear from you if you have any suggestions on how we could make DMDirc more intelligent. Feel free to leave a comment on this post, create a new issue on the issue tracker, join us in #DMDirc on Quakenet, or use the feedback form found in the Help menu in the client itself.

Looking back on the 0.6 branch, one of the things we’d like to change most is the length of time between each release. Ignoring security and bug fixes, there was a four month gap between 0.5 and 0.5.5, and it looks like DMDirc 0.6 will be released between six and seven months after that. This isn’t because we’re getting lazy, or because we care less about DMDirc than we did when we released the first few versions (which were all inside of the same month); it’s because we’re implementing more features, fixing more bugs, and doing more behind-the-scenes work (improving the DMDirc code base) than we have in previous releases. To combat this somewhat, we’re aiming to make three releases as part of the 0.7 development series – DMDirc 0.6.3, 0.6.6 and 0.7. We’ve allocated issues to each release to try and balance the time it will take (DMDirc 0.5.5 wasn’t a pre-planned release and, as you can tell from the timing, didn’t split the workload too well), so hopefully we’ll be able to make releases somewhat more frequently than we have been.

Pre-planning these sub-releases has also enabled us to organise issues better so that we’re working on (and releasing) related features at the same time. The rough focus of each release is described below. Note that these are just the major, overarching themes; each release also contains a good helping of smaller, independent enhancements.

• DMDirc 0.6.3: Server lists, input/command improvements, plugin improvements
• DMDirc 0.6.6: Updater overall, installer and launcher improvements
• DMDirc 0.7: Channel and general window/UI improvements

Of course, if you can’t wait for releases to try out all the new features, you can download a nightly build, which can auto-update with the latest features and bug fixes each day.

We have also relocated our subversion repository from its previous home at Google’s Project Hosting service, to our own server. We made this switch because of the fairly poor uptime of Google’s offering, and the seemingly random delays between commits being made and announcement e-mails being sent. If you have the DMDirc source code checked out from our subversion repository, follow the instructions here to migrate to the new repository.

If your machine fits the bill, you can download the developer preview from the Apple Developer site:

• Go to http://www.apple.com/java
• Click on “Java Downloads”
• Click on “Java SE 6 Developer Preview” — This will redirect you to the ADC site.
• Login to the ADC site (you may need to register first.)
• Click on “Downloads”
• Click on “Java” in the sidebar
• Download the “Java SE 6 Developer Preview”
• Install

Once you have the developer preview installed, you can download a nightly build of DMDirc from http://www.dmdirc.com/nightlies or you can build your own by checking out the source code from our subversion repository (if you have the developer tools installed) by running the following commands:

svn checkout http://dmdirc.googlecode.com/svn/trunk/ dmdirc
cd dmdirc/trunk/installer
./release.sh --target osx this
mv output/DMDirc.dmg ~/Desktop/DMDirc.dmg


Now you can mount the image, and drag DMDirc to the applications folder to install it.

However, at the moment there is a bug with the “First Run Wizard” that we use to extract plugins and actions for the first time, so you will need to run the following in a terminal prior to running the client to make it work. This assumes that you installed DMDirc into the Applications folder and not somewhere else.
Edit: This bug has been fixed.

mkdir -p ~/Library/Preferences/DMDirc/
cd ~/Library/Preferences/DMDirc/
unzip /Applications/DMDirc.app/Contents/Resources/Java/DMDirc.jar plugins/*.jar com/dmdirc/actions/defaults/*
mv com/dmdirc/actions/defaults actions
rm -Rf com
echo "general.firstRun=false" >> dmdirc.config
echo "general.addonrevision=10" >> dmdirc.config
echo "updater.enable=true" >> dmdirc.config
echo "general.submitErrors=true" >> dmdirc.config


The last two lines can be omitted if you do not wish to receive update notifications, or automatically send error reports to the developers. We would however prefer you to have them both enabled.

Now you can enjoy DMDirc on OS X :)

Feel free to raise any issues on our bug tracker, leave a comment here, or contact us in #DMDirc on Quakenet

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.

0.5 has just under 100 features or improvements and 77 bug fixes since 0.4, the major additions in 0.5 are

* Added action wrappers for aliases and performs
* Added intelligent tab completion for commands
* Added server settings dialog
* Added support for themes
* Added support for character transcoding
* Added support for various command-line options
* Added installers for Windows and Linux

See the changelog for more information on this release. As always we recommend existing users to upgrade, and non-users to give it a go, come visit us in #DMDirc on Quakenet (see the help menu) with your feedback or just to visit.

0.5 can be downloaded for windows and linux

The /ctcp command: type /ctcp someone <tab><tab>, and instead of getting a standard tab-completable targets (such as command names, channel names, etc), you get the following:

00:03:18 | Multiple possibilities: VERSION, ACTION, USERINFO, CLIENTINFO, PING, FINGER, SOURCE, TIME

The /loadplugin and /reloadplugin commands allow you to tab complete the class names of relevant plugins.

One last example: the /set command allows you to tab complete both the domain and option names, so instead of /set general showcolourdialog, you can type /set g<tab> sh<tab>c<tab>.

This may not seem like much, but once you get used to using it, it’s hard to cope without it!

0.4 Brings many improvements over previous versions, with over 500 svn commits since 0.3, 0.4 includes amongst other things:

• The actions system (See these two blog posts)
• The plugins system (See this blog post)
• Completely new, faster, text pane
• Searching
• Over 100 improvements bug fixes

See the changelog and readme for more information on this release. We encourage existing users to upgrade, and non-users to give it a go, and let us know in #DMDirc on Quakenet what you think :)

0.4 can be downloaded here

I’m Chris, aka MD87. I’m the “core” developer of DMDirc, which means I’m responsible for most of the back-end logic, handling data storage, and a small mountain of others things. I’m also apparently the best writer, so I’ll probably be the one who posts most to this blog.

Next up, we have Shane, aka Dataforce. He’s primarily in charge of the IRC Parser (the code that interfaces between the client and the IRC server), but is also working on the plugins system, and writing the logging plugin. You can identity Shane’s code by the length of lines and the number of code conventions it breaks (if there are >300 char lines, and it breaks every convention you can think of, it’s probably his).

Last but not least, there’s Greg, aka Greboid. He’s in charge of the client user interface, and can often be found complaining on IRC about problems he’s having with it (his latest favourite subject is the TextPane rewrite we have scheduled for 0.4).

So, that’s us. We can all be found on IRC, in #DMDirc on Quakenet (irc.quakenet.org) among other places. We can also be contacted via e-mail by prepending our name (as above) to @dmdirc.com.

If you want to try the features we’re describing, you can try a nightly build, as explained on the development page of our main website. Please note that nightly builds may be horrendously buggy, so don’t be hugely surprised if one of them deletes your config files, makes your screen turn red, or sacrifices your first born child to the gods of IRC.

If you have any questions about DMDirc, want us to blog about anything in particular, or just want to chat, you can find all of the developers in #dmdirc on Quakenet (irc.quakenet.org).