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!

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.

To pre-emptively answer a few questions:

• Condition Trees are called Trees because of their implementation, rather than their function. Each ConditionTree object has exactly one operation (and, or, not, noop [used for empty brackets and trees] or var [used to look up the result of a condition]), and zero (in the case of noop or var), one (in the case of not) or two (in the case of and and or) child condition trees.
• The title of this blog post is a reference to a question another developer asked when I was talking about condition trees – it went something like “are you *trying* to make the actions system more incomprehensible?!”; my reply: “no, I’m trying to make it more powerful; incomprehensibility is just a side-effect”.
• We will be having a UI for condition trees in 0.6, but we’re not entirely sure of the details yet. Stay tuned for details later in the development cycle.

Substitutions
In 0.4 actions substitutions were somewhat of a black art, whilst they were quite powerful, they were nearly impossible to figure out, so we have added a UI component to both the actions response panel and condition editor making them much more accessible. When editing either of these you will be able to access a full list of available substitutions, which can be added at the current cursor position either by double clicking or using the button, or added any any position you like by dragging and dropping them.

Aliases

Perform

Unfortunately, with something as flexible as actions, it’s hard to get the UI right the first time around. For DMDirc 0.5 we’re introducing a few minor changes which will hopefully make creating and editing actions easier.

The first of our two tweaks is a change in the behaviour of the actions manager. In DMDirc 0.4, to edit an action you need to click the group tab (if it’s not selected), move your mouse down to the action, click on it, and then mouse all the way over to the edit button (taking care not to hit any of the six other buttons that line the bottom of the manager). In DMDirc 0.5, you can simply double click on an action to open it in the editor.

The second tweak is a change to the “Trigger” drop down menu in the actions editor. In DMDirc 0.4, this is a long list that only has a vague sense of order (in fact, the order of items in the list is the order we defined them in code, which is generally based more on when they were added, rather than what they’re for). In DMDirc 0.5, the triggers list is split into distinct groups, and the triggers within a group are sorted alphabetically, making it much easier to find what you’re looking for. Before and after pictures are below, although they don’t do the changes much justice, thanks to the rather limited size of the dropdown menu.

We have several more improvements planned for the actions UI before 0.5 is released, and we also have some brand new UI to make using certain types of actions even easier, which we’ll be blogging about later.

The actions manager lists all known actions, sorted into groups (which correspond to directories on the disk).

The “general” tab of the actions editor allows you to select which triggers the action responds to, as well as specifying its friendly name.

The “conditions” tab allows you to specify conditions for the action. The pencil icon brings up the condition editor for that condition (see next image), while the cross button deletes the corresponding condition.

The conditions editor allows you to add or modify an action condition. Once you select an argument, the components list is updated to contain only the applicable components, and when you select a component the comparison list is updated similarly.

Finally, the response tab allows you to specify how the client should respond if this action is triggered. The commands are executed as though you typed them in the window that triggered the event.

The graphical front-end for actions is still under construction, but the back end has been fully functional for a week or so. Here’s an example of one of the actions I use:

trigger=CHANNEL_USERAWAY
conditions=0
response=/setnickcolour $source 14

This rather brief action makes the client colour anyone who is set away to a light grey colour. (Aside: DMDirc can now be configured to send /who requests at a certain interval (60 seconds, by default). This functionality can also be enabled and disabled per channel; if it’s disabled then the CHANNEL_USERAWAY events won’t be triggered unless the user manually sends a who request). The ‘trigger’ field specifies which event triggers the action (and may, as we’ll see in a minute, contain more than one event); the ‘conditions’ field tells DMDirc how many conditions there are for the execution of the action – in this case, none; finally the ‘response’ field contains commands to be executed (or text to be sent to the channel) – here it uses a recently-introduced command to set the colour of a specified nickname. The “$source” part will be explained shortly.

Here’s a slightly more complex action:

trigger=CHANNEL_MESSAGE|CHANNEL_ACTION
conditions=1

condition0-arg=2
condition0-component=STRING_STRING
condition0-comparison=STRING_CONTAINS
condition0-target=$nick

response=/notify $highlightcolour\\n/popup Highlight on $chan: <$source> $message
format=channelHighlight

Here we have two triggers: CHANNEL_MESSAGE and CHANNEL_ACTION. If multiple triggers are specified, they have to be type-compatible (they must have the same number of potential arguments, which must be of the same classes) – this restriction, like any others mentioned hereafter, will be transparently enforced by the graphical editor, so there will be no need for users to worry about this.

Unlike the previous example, this one also specifies a condition. There are four parts to a condition: the argument, component, comparison and target. The first two determine what the user wants to test – the argument identifies which object they’re interested in (e.g. a Channel or User), and the component determines which aspect of that they want to test (A channel’s name, a user’s modes, etc). The comparison, rather unsurprisingly, determines what comparison should be used to compare between the test subject and the user’s target. Some comparisons for strings, for example, are “starts with”, “contains” and “equals”. The target, as implied, is the data that the subject is compared to. An action can have any number of conditions, and will only be executed if all of them pass.

In this example you’ll also notice that the ‘response’ field contains two commands (both new since 0.3), which are both executed. It also contains a few variables. These are dynamically replaced when the action is being tested and executed (they can appear both in the response and the targets of any conditions). The exact replacements available depend upon the arguments – $source will be set to the user’s nickname if the action was triggered by someone, and $chan will be set to the channel name if the action is channel-based, for example. Others are always present (such as $nick, used in the condition, which equals your current nickname on the server that the action is being executed for). The actions system will also replace any variable with the same name as a config setting under the “actions” domain – in the example above, the $highlightcolour variable is replaced by the value of my ‘actions.highlightcolour’ setting.

Finally, we have the ‘formatter’ field. This allows the user to control the default output that is normally associated with an action. In this example, it changes the formatter name from ‘channelMessage’ (the default), to ‘channelHighlight’, which is a new format I’ve written which makes the line show up red. You can use this to stop default messages entirely (by setting the formatter to an empty string), or, for example, to display a custom message if a certain event happens.

You can try out actions in the latest nightly builds. There is a pack of actions available here that provide some basic functionality for changing the colour of channels in the treeview (joins/parts/quit make the channels turn green, messages make them turn blue, and highlights turn them red).