Regular visitors to our blog may have noticed a lack of development roundups over the past few months. This was due to some non-DMDirc commitments/difficulties experienced by some of the developers. Never fear, though, we’re now back and gearing up for DMDirc 0.6.3m2, which should be out on the 1st of November according to our release schedule. We’ll try to clear up the backlog of roundups over the next few days.

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.

During May the DMDirc developers were gearing up to release DMDirc 0.6.3m1 (which has just been released: see our previous blog post), the first of our “milestone” releases on the way to 0.6.3 proper. During this month we made 113 commits to our git repository, fixing over 30 issues. Some of the more notable changes this month were:

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

April was a fairly slow month for the DMDirc developers. One of our biggest time sinks this month was fixing problems in the UI which appeared after we made some changes to improve thread safety. Throughout the month we had both major and minor issues related to window switching and maximising/restoring, some of which we’re only just getting around to fixing now.

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

March was a reasonably busy month for us, with 160 commits to our central repository.

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

Welcome to the second instalment in our monthly series of development roundup blog posts. February was a much busier month for us than January, with quite a few major changes, and over 280 commits made to our git repository.

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