<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.

Window menu enhancement

The window menu now groups windows by server, making it much easier to quickly access a specific window (especially if you’re connected to lots of different servers!).

Addon browser

The addon browser was previously available in 0.6.3m2, but was not properly functioning in that release. DMDirc 0.6.3 presents a functioning addon browser, allowing you to browse through plugins, themes and action packs from within DMDirc, and download and install them with one click.

Backgrounds

You can now specify background images for both the textpane and the main ‘desktop’ area.

Topic improvements

A brand new topic bar now adorns the top of channel windows, allowing you to easily see the current topic at a glance, and edit it right from the channel. The topic history display in the channel settings window has also been completely revamped, showing much more detail than it did previously.

Improved URL and channel linking

DMDirc’s already intelligent URL handling has been improved further, now allowing some extra characters to ensure compatibility with non-standard URLs. We’ve also applied the same techniques we use for intelligent URL linking to channel name links, so trailing punctuation and brackets will no longer get in your way when trying to join a channel.

DCC fixes

We’ve fixed a whole raft of bugs in the DCC plugin, which should make it work much more reliably in more circumstances than ever before. We’ve also fixed a particularly silly bug which rate limited all DCCs to 10KB/s in past versions.

As always, we welcome bug reports and feature requests on our issue tracker, irc channel or as comments on this post. We will also respond to mentions on twitter. DMDirc 0.6.3 continues to be supported on Linux, BSD, Solaris, OS X and Windows, as well as having a standalone Jar file for any other java-capable platforms that are not specifically supported.

1. Create a new tag in a local Git repository
2. Push the new tag
3. Run the relevant ant task to create an installer
4. Upload the installers and jar file to the correct place
5. Go through each plugin and upload each one (one at a time) to the addons site
6. Find or clone a copy of the main website repository
7. Update a PHP file to contain details of each supported OS and each download and its size, etc
8. Commit the website changes
9. Push the website changes

Obviously, this process was distinctly not enjoyable. A lot of it now lends itself quite well to being automated, but we hadn’t tried this in the past for various reasons (such as our use of SVN prior to Git, and the huge length of time between releases prior to the introduction of our fixed-length release cycle). Now we have the tools and the motivation (we don’t want to be doing that process every four months for each alpha, beta, release candidate and stable version!), we set about automating the entire procedure.

We already had a set of scripts which monitored our Git repositories for new commits, and did various useful things such as announcing the commits to IRC and updating our bug tracker. Some extra code was introduced for commits to the client repository that checks if the commit looks like a release, determines which updater channel it’s for (alpha, beta and rcs are unstable, plain versions are stable), and then builds the relevant installers. Once the installer’s built, it copies or uploads the files as appropriate, automatically updates the website as needed and commits and pushes the changes, and then automatically submits every plugin to the addons site. This means our release process is now:

1. Create a new tag in a local Git repository
2. Push the new tag

Which I’m sure you’ll agree is decidedly simpler. Of course, we still have to announce the release to the world. Anyone wanting to develop an artificial intelligence to automatically create changelogs, release notes, blog posts, news stories and tweets for each release should get in touch!

Anyone who is still using an SVN checkout should read http://www.dmdirc.com/git and switch to using Git, which brings numerous advantages and makes contributing back to DMDirc easier thanks to Gerrit.

If you have any questions about DMDirc development, feel free to join us in #DMDirc on Quakenet.

Recently we began a trial of using Gerrit to manage commits made to the main DMDirc repositories for the client and the parser. Gerrit is a code review tool, which developers submit their changes to (instead of pushing them directly to the Git repositories); other developers can then review the changes, test them, and leave feedback, before ultimately approving or rejecting the change. Only once a change has been approved is it allowed to go into the repository.

This has helped us greatly improve the quality of the code that makes it into the client. Another advantage to using Gerrit is that it now allows us to open up the repositories a bit more and allow third-party contributions with much more ease than before: it is now possible for anybody to sign up to Gerrit and begin committing to DMDirc right away! We even have a guide on our Git wiki page detailing how to do just that.

If you would like to contribute to DMDirc, either by committing (via Gerrit!) or in other ways, we suggest paying a visit to #DMDirc on either Quakenet, Freenode, OTFC, Coldfront or Chatspike! (Don’t worry: we have a system in place to link all the channels together!)

DMDirc 0.6.3m2 is the second milestone release since 0.6.1, and the first release we’ve made as part of the fixed cycle. It contains a large number of bug fixes and minor improvements.

As this is the first release as part of the fixed release cycle, we weren’t used to the limited timescale between releases and as such our usual ‘quiet’ period between releases had a much larger effect than it does normally. This means that we didn’t get as many features into this release as we would have liked, but we still managed to squeeze a few in:

Textpane font settings

One of our most requested improvements – you can now set both the font name and size of the text displayed in DMDirc’s textpane. The options can be set globally, per-server or per-channel as usual.

Alternate parsers (Twitter support)

DMDirc can now support different parsers in addition to our previous IRC parser. This means better or alternative IRC parsers can be developed in the future, or we can develop parsers to interact with completely different systems. As a proof of concept, we’ve developed a Twitter parser which allows you to read your Twitter news feed and post status updates direct from DMDirc!

Configurable server names

You can now configure how DMDirc displays server names in the treeview and the titlebar. This means you can (for example) show your nickname along with the server name (useful if you often connect to the same server twice as different users), or show the network name instead of the server address (in case you use a bouncer to connect to multiple networks).

License panel

We’ve also tidied up the ‘License’ panel in the about dialog, to make it much clearer which components are covered by which license. This should make it easier for anyone interested in modifying DMDirc or reusing parts of it to see where they stand.

As we’re now committed to releasing on a fixed schedule this will be the last ‘milestone’ release, and for future releases we’ll just add to the minor version number until we’ve implemented the features targeted for the next major release. This means the next release will be 0.6.3, and any further releases before the 0.7 feature set is complete will be 0.6.4, 0.6.5, etc

As always, we welcome bug reports and feature requests on our issue tracker, irc channel or as comments on this post. We will also respond to mentions on twitter. DMDirc 0.6.3m2 continues to be supported on Linux, BSD, Solaris, OS X and Windows, as well as having a standalone Jar file for any other java-capable platforms that are not specifically supported.

So, going back to June. Almost the entire month was spent in a feature freeze for DMDirc 0.6.3m1. We made around 70 commits to our git repository, fixing a large number of bugs ranging from typos, to windowing/title problems, and various minor UI tweaks.

On the 28th of June, we released DMDirc 0.6.3m1, the full changelog for which can be seen on the wiki.

• 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!

• Default settings changed from being versioned using SVN revision numbers to using Git commit hashes, which fixes a lot of development error and further paves the way for us to drop SVN support entirely,
• Several fixes to the profile manager dialog
• Fixed bug where updater forgets about updates if it checks again, and tidy up some of the updater code
• Many, many fixes to the DCC plugin which means that it now works on a regular basis
• Further work on the preferences dialog (including a fix for the long-standing problem relating to plugin icons under Windows)

All of these changes made it into DMDirc 0.6.3m1, which we encourage you to check out. As always, you can leave feedback here, join us in #DMDirc on Quakenet, use the feedback functionality in the client, or have a word with @DMDirc on Twitter.

• A redesign of the preferences dialog
• Improved support for SSL certficates (both client and server)
• Support for SOCKS proxies
• Ability to automatically restart the client after installing updates
• Ability for plugins to specify ‘services’ that they provide/require.
• Ability for plugins to export (share) methods with each other
• Improved MDI support
• A more robust DCC plugin
• Moving of the UI to a plugin, allowing for it to be updated separately from the main client

DMDirc 0.6.3m1 is one of our “milestone” releases of the 0.6.3 branch. These milestone releases were a (somewhat failed) attempt to release more often than we have in the past. We periodically decide to stop working on any new features and tidy up the current code-base into a release-ready state to allow users of the stable branch of the client to get some of the new features and fixes we have added sooner than having to wait for a full major release. It’s taken us almost a year to get to 0.6.3m1, so imagine how long it’d take if we went straight to 0.6.3 itself (which is approximately two milestones away)!

Users of previous versions of DMDirc should in the coming days be prompted by the automatic updater (if enabled) to update to the latest version of DMDirc. Alternatively, you can visit our downloads page to grab the latest version yourself.

With DMDirc 0.6.3m1 released we are now looking forward to our next milestone release, DMDirc 0.6.3m2. So far the issue list for this contains exciting additions such as improved handling of different charsets in channels, additional changes to plugins to try and make them less like black magic, server lists, improved support for netbooks (and other low-resolution systems), and a plethora of other bug fixes and general improvements to make the client nicer to use.

As always, we welcome bug reports and feature requests on our issue tracker, irc channel or as comments on this post. We’ve also recently launched an official twitter presence. DMDirc 0.6.3m1 continues to be supported on Linux, BSD, Solaris, OS X and Windows, as well as having a standalone Jar file for any other platforms that are not specifically supported.

There were a couple of new features introduced this month, such as the ‘restart needed’ dialog which appears when the updater determines that you need to restart the client in order to complete the upgrade process. If you elect to restart using this dialog, the client will close and the DMDirc launcher will automatically reopen the (updated) client.

The windows side of this was done by a new addition to our team, Michael ‘Zipplet’ Nixon, who has now taken responsibility for all of our code that’s native to Windows (primarily the Windows launcher, installer and uninstaller). Previously Michael helped us test DMDirc on Windows, and we’re very grateful that he’s now joined us as a developer. So far he’s helped to clean up a lot of the Windows code, and has fixed several major bugs such as the uninstaller not working.

As always we encourage you to try a nightly build and to provide us with any feedback you have, either as a comment here, on our bug tracker, or in #DMDirc on Quakenet (irc.quakenet.org).

To begin with, we’ve made some changes to the way we version our non-stable releases (including nightly builds). Previously, these were versioned using an SVN revision number which lead to problems when we created new branches — if we created a branch of 0.5 and committed a single change right now, it would have a higher revision number than DMDirc 0.6 or the latest nightly builds; this created lots of problems with updating and plugin version requirements. We now use a description of the git commit for versioning, so our example 0.5 branch would have a version along the lines of 0.5-1-gabcdef1 (which means it’s 1 commit after the 0.5 tag, and the commit has an abbreviated object name of abcdef1), while more recent builds would be along the lines of 0.6-801-g123456a. You can plug these version strings straight into almost any git command, or our git web interface to see exactly what is included in that version.

Following on from the plugin changes described last month, we now allow plugins to define their default settings in their plugin.info files, along with any custom formatters and icons they use. This moves a lot of static information out of the plugins’ classes and into more easily altered configuration files. It also allows our addons site to parse this extra information (so we could in the future provide a list of options a plugin accepts, for example). We also updated our plugin build script to be able to cope once again with “friendly” version names, so nightly users will once again see proper version numbers instead of SVN revisions.

We’ve also made some changes to the way our IRC Parser works, which allowed us to remove over 4,000 lines of code from the package. The change should be transparent to any developers using the IRC Parser in their own projects (aside from the sudden decrease in number of classes!). The change means slightly smaller download sizes for our users, and much easier maintenance for us going forward.

As always we encourage you to try a nightly build and to provide us with any feedback you have, either as a comment here, on our bug tracker, or in #DMDirc on Quakenet (irc.quakenet.org).

One of the most major changes made during February was the moving of the main DMDirc UI to its own plugin. This enables us to update the UI independently of the client, and in the future will result in smaller downloads when updating either the client or the UI. We also took the opportunity to upgrade MiG Layout, the layout library used by the Swing UI, to the latest version, and now include it in our repository as a .jar rather than extracted in source code form. This makes our source tree much tidier, makes it easier for us to update to new versions in the future, and means we can now bundle the library with our UI plugin instead of the client itself.

The next large change we made was a partial revamp of the plugin system. Plugins can (and should!) now use DMDirc-style configuration files (such as those used for actions, in themes, and of course by the config system). We also introduced a system of ‘services’ to plugins, aimed at improving how plugins worked together and decoupling plugins from one another. Plugins can now define which services they provide (both to the user, and to other plugins), such as status bar applets, nowplaying media sources, or ways to interact with the user’s computer (such as the dcop plugin); they can also require certain services be loaded, so plugins written for the Swing UI can require that the ‘swing ui’ service is provided for it.

With these plugin changes, we also gave plugins a way to declare certain methods for ‘export’ to other plugins. For example, the dcop plugin now exports its getDcopResult method under the alias ‘dcop’, and the dcop media source plugin requires a plugin which can provide this export. If an alternate dcop plugin is written, the dcop media source plugin could work with it right out of the box. In the future we hope to use this method for the nowplaying plugin’s media sources, and perhaps even the user interface plugins.

Still on the subject of plugins, we also introduced ‘subplugins’ this month. Sub-plugins allow a ‘child’ plugin to access classes defined by the ‘parent’ plugin. Previously, the only way to accomplish this was to make the parent plugin persistent, which meant that it was not possible to unload or reload it. Defining this relationship formally also allows us to present it to the user when we upgrade the plugins panel in the preferences dialog (slated for 0.6.3 — watch this space).

There have also been several major back-end changes, the effects of which won’t be immediately obvious to users. These are the conclusion of the command parser changes and a slight redesign of the configuration system. The former allows for more flexibility in how we assign commands, makes the processing of some commands more efficient, and fixes some issues we had when splitting command input into arguments. The configuration changes now mean that the defaults for all DMDirc settings are specified in a configuration file; previously, developers could either add them to the file or specify the default as a fallback option when they requested the setting (or both!). This change means that all settings are now listed and tab-completable with the /set command, and means that we no longer have to hunt down every use of the setting when updating defaults.

As mentioned in last month’s roundup, we’ve been putting the finishing touches to our reworked preferences dialog. Users of nightly builds will have noticed that it now opens near-instantaneously, and does the heavy work of loading categories in the background. Another long-running project which landed this month is an improvement to the textpane designed to reduce memory usage and pave the way for more features (such as being able to copy control codes) in the future. Finally, we finished enhancing our support for SSL-enabled servers; DMDirc is now capable of validating the SSL certificate used by servers, and presents the user with a dialog if there are problems.

This month there were 67 issues resolved, so unlike last month we won’t be including a list in this blog post. Anyone interested can browse the full list on our bug tracker, here. See you next month!

You can try out the latest developments in DMDirc before the next release by using nightly builds, available from the main website. Be warned that nightly builds aren’t tested extensively, and may be quite horribly broken. Finally, as always, we’re happy to receive feedback or to help out with problems; the easiest way to find us is to drop by #DMDirc on Quakenet (which you can get to easily by using the ‘Help’ → ‘Join dev channel’ menu option in DMDirc).

January was a fairly slow month for us, with only 57 commits made to our collective git repositories. We have, however, made progress in a variety of areas, including a major refactoring of the command manager to allow greater flexibility to command authors, and further improvements to our new-look preferences dialog.

Issues marked as fixed this month:

• 0001812: Expanding and collapsing treeview makes nicklist a stupid size
• 0001874: Ctrl+c doesn’t work as expected with find bar open
• 0002017: Can load windows np sources on linux
• 0002043: The arrows for collapsing/expanding the treeview/nicklist are ugly
• 0002056: Line length calculations use char length not byte length
• 0002057: java.lang.NullPointerException — Query.getMaxLineLength(Query.java:167)
• 0002066: text can be sent twice by very quick repetitions of the enter key (and im sure awful pcs!)
• 0002067: alias dialog edit panel not 100% width
• 0002070: UI line splitting needs to use bytes not chars
• 0002071: java.lang.StringIndexOutOfBoundsException: String index out of range: 460

February is already shaping up to be a much busier month, with the number of commits made almost double that of January already. Major changes so far include the finishing touches of the reworked preferences dialog, a huge change in the way that the user interface interfaces with the client, and a number of changes to the plugin system. Details of all of these will be in next month’s roundup.

You can try out the latest developments in DMDirc before the next release by using nightly builds, available from the main website. Be warned that nightly builds aren’t tested extensively, and may be quite horribly broken. Finally, as always, we’re happy to receive feedback or to help out with problems; the easiest way to find us is to drop by #DMDirc on Quakenet (which you can get to easily by using the ‘Help’ → ‘Join dev channel’ menu option in DMDirc).

After a long period of testing we have finally released DMDirc 0.6, and we think this is the best version of DMDirc to date with over 250 feature additions, bug fixes and other changes, including:

• Themes system revamp to allow multiple themes to be loaded at a time
• Completely redesigned Actions Manager and Actions Editor dialog (see our previous coverage of these)
• New installer for OS X
• The Linux installer can now be used for BSD-like OSs that have Java pre-installed
• The Linux installer can now be used on Open Solaris
• The automatic updater can now update plugins

As of DMDirc 0.6 we now support running on more platforms than before: we have installers for Linux, BSD, Solaris, OS X and Windows, as well as a standalone Jar file for any other platforms that we don’t currently provide an installer for.

Users of DMDirc 0.5.6 (or the recent unstable releases) should be prompted by the updater (if enabled) to update to the latest version of DMDirc. Alternatively, you can visit our downloads page to grab the latest version yourself.

With DMDirc 0.6 (finally!) released we are looking forward to our next release, DMDirc 0.6.3. This will include support for SOCKS proxies, improved support for SSL Servers, a nicer looking Preferences dialog, server lists and more.

As always, we welcome bug reports and feature requests on our issue tracker, irc channel or as comments on this post.

As you can see from the screenshot we now show an info blurb, version and author for all action groups that provide them. In the future, we plan to allow users to edit action groups’ meta-data from inside the UI. This will make it a lot easier for end users to create action packs and make them available to a wider audience through our addons site, but for the moment only the name of the group is editable.

Settings for a particular group are now displayed underneath the group and are editable using the same components as the preferences dialog. Exposing these to the end user has added a lot more flexibility to actions and should enable them to be used in much nicer ways.

Finally, in the previous incarnation ‘wrapped’ actions groups (such as profiles and aliases) were visible but appeared empty. This was rather odd behaviour, so we remedied this and now show the contents of all groups. This allows users to edit the automatically created actions, so they can see how they work or use more advanced features that the wrapper UI doesn’t expose. The new UI is also a lot more pleasing to the eye.

Of course, the Actions Manager is only half of the actions UI; the Actions Editor has also undergone a revamp in 0.6. In DMDirc 0.5.5, we introduced Condition trees, but at the time they were only usable if you manually edited the action’s file in your profile, something which we don’t expect normal users to do. The new Actions Editor UI exposes condition trees and allows for easy selection of ‘AND’ and ‘OR’ trees, which should bring the added power of condition trees to more users.

As with the Actions Manager, we think the new Action Editor is much more user friendly than its previous version. You can, for instance, now see all the information about the action on one screen and edit them easily without having to switch between tabs. Of course, we’re always willing to improve further, so if you have any suggestions, please leave a comment!

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.

As you probably know, DMDirc is written in Java which gives us a huge advantage as far as cross-platform compatibility is concerned. Java runs on all the major operating systems so most of the hard work has been done for us.

Up to DMDirc 0.5.6 we only supported Windows and Linux and provided a separate jar-only download for other platforms. For 0.6 the supported list of operating systems has more than doubled; we now package DMDirc for:

1. Linux
2. Windows
3. OS X
4. Open Solaris (and normal Solaris)
5. BSD (tested on PC-BSD, which is FreeBSD at the core)

This pretty much covers all major non-server operating systems, which we are quite pleased about.

The Installer for DMDirc runs on all of the above systems (apart from OS X, which has its own installation method) and where possible can download and install Java automatically. Currently the only exception to this is BSD, where users will need to compile the jdk16 port manually — unfortunately Sun’s licensing prevents redistribution of the modified JRE used on BSD.

The nightly builds have been working on all of the above operating systems for a while now, and you can browse and download the installers from our nightly builds page.