Understanding the config.xml file from ExQueues Shell Queue GPL by Slain Jamison Wilde

ExQueues uses a relatively complicated method for storing its configuration data, namely in an xml-style configuration file called 'config.xml'. This file should be located in the user's application data folder under ExQueues, to allow for multiple users on the same machine to have different settings.

This file is both read (and when complete written) by pugxml (the Pug XML Parser).

In the text below, there will be discussion of attributes and <Attribute> tags. 'attributes' are the key="value" we are all familiar with in XML. The <Attribute>s are ExQueues specific tags used to indicate values and options for particular task and task queue types.


XML Attributes


The XML tags can have various attributes which will be described here:

display="Display this in the config control"


Generally used in a section tag, such as <General>, this will be used instead of (overriding) the tag name in the Tree control used to display and modify the config data. So for example, <General display="General Settings">



Generally used to indicate a particular instance of a tag, such as <Option name="ExtractVIDEO_TStoFolder"> to indicate which setting this option is referring to. In most cases, you may also use a sub tag <Name value="MyName"/> or <Name>MyName</Name> to indicate this information. This alternate formatting may not remain once resaved after editing in the config tree control, though.



Used to indicate the value of a particular tag, whether it is a string, number, or boolean. For example, <Option ... value="true"> indicates a boolean true is the value. In some cases, you may also use a sub tag <Value value="MyValue"/> or <Value>MyValue</Value> to indicate this information. This alternate formatting may not remain once resaved after editing in a the config tree control, though. Values will often times indicate lists of values, separarated by commas, such as lists of directories, or lists of extensions. When indicating lists of directories, if a path contains a space then that path should be surrounded by double quotes. Ex.: c:\firstpath, "c:\second path", c:\thirdpath



MyDataType must be one of (string, int, bool). Inidcates that the data should be interpreted as a string, a boolean or an integer. This is most useful in helping determine how to display the control for a value in the config control, whether as an editbox for a string, a checkbox for a boolean, or a number edit box for an integer.



Used in <Option> and <Attribute> tags, this indicates the default value for an option setting or ExQueues attibute, such as <UseRecylceBin type="bool" default="true"> for the <UseRecycleBin> option setting.



Used to determine if a section or tag will appear in the config tree control. This is for settings that shouldn't change, such as the ExQueues <Attribute> tags which describe the other data in the document. Changes to these would need to be made by hand in the xml document.



Not really used by the application at this time, these simply indicate and differentiate between tags that would otherwise be identical, but contain desparate data. For example, <Task number="1"> and <Task number="2"> indicate that these are different tasks (xml-wise), but this isn't really used by ExQueues at this time and may go away.



As indicated in name= and vaue= above, sometimes PCDATA (data in between two tags) is allowed. For example, <Name>MyName</Name>, where MyName is the PCDATA.


XML Section Tags


The file contains various sections which will be described in further detail here.



The containing tag for the document is the <Config> tag, in which all other relevant section and data tags will be found.



The section for general settings for the application are contained in the <General> section. Within this section, the actual data for the settings is contained in <Option> tags.

All of the options are self-explanatory, if one also looks at the <Tips> tags inside each <Option>. These options are editable within the config tree control. Developers adding additional options should make sure that the option name is unique, that a default is provided and that the type is set.



This section contains all of the various possible attributes that can be used to describe a task or task queue in ExQueues such as Repair or Extract. The value types and default values for these task attributes are also established in this section, including tooltip text describing the function of each attrribute for display in the config tree control.

Examples of attributes are MenuText, MenuShow, UseRecycleBin, DeleteSources, MenuDestinations. Each <Attribute>, like an <Option> has a name attribute, a type (string, bool, int) attribute, a default attribute to indicate the default value in the absence of other information, and a sub-tag <Tip> used to show tooltips in the config property tree control.



The <Vars> section contains sub-tag <Var>s, that can be used as substitution variables for frequently used values. For example, many times the <MenuDestinations> <Attribute> uses the same directories in most of the <Task> types. You could use a <Var> to represent those destination paths that repeat in most tasks. You would then use :: (colon colon) in front of the name= attribute you chose for your <Var>, to have the variable name substituted with its value. For example, by default in the config.xml file there is a <Var name="varDests">. Set this variables value to be your most common destinations. You could then use the value of varDests in a <MenuDestinations> <Attribute> by writing '::varDests'. If you wanted to add additional paths after, you could use '::varDests, c:\My\Other\Path' for example (w/o quotes).



Contains all of the Task Specific information for a single task (not a task queue, with the exception that deleteing the source files after successful completeion of a task can create a secondary task when requested). Examples of atomic tasks are Repair, Move, Copy, Extract, Delete. <Task> tags contain several tags (derived from <Attribute> tags listed in <AttributesInfo> section). The only mandatory <Attribute> tag is the Name tag (or name= attribute in the <Task> tag). Refer to the tips in the config.xml file regarding specific information about various <Attribute>s.



Contains all of the task queue (sequential tasks triggered by one action). The current example is "Repair then Extract", where two atomic tasks (Repair, Extract) are chained together in sequence. Queues contain many of the same Attributes as tasks.

Queues contain an ordered list of <Task>s to indicate which tasks should be used and in what order they will be executed. Default values for these atomic <Task>s can be overridden as well in the <Queue> <Task> tag.



This section describes how a DDE request is converted into a Task or Task Queue when recieved, based on the file extension(s) of the data. For example, if a user drags and drops one or more repair (.par2) files in Directory Opus into another folder, the default action for ExQueues is to begin a "Repair Then Extract" Task Queue for each file. If a repair file and an archive file (.rar) are dragged and dropped to the same folder, then a "Repair Then Extract" Queue is created for the .par2 file and an "Extract" Task is created for the .rar file. If an NFO file is also dragged at the same time as the other .par and .rar, then instead of Repairing or Extracting, ExQueues will simply move all of the selected files.

The <DDE> section contains <Command>s that represent a single DDE action, such as a drag and drop DDE command or ctrl-delete. Each DDE command has a specific name, such as 'delete' or 'queue' (which are built-in) or whatever the user decides to create. Each <Command> then has one or more <CommandGroup>s, representing groupings of Tasks/Queues that could be used to process that command. For example, the 'queue' <Command> has two <CommandGroup>s. One is for handling if all of the file are .par2's or .rar's, so that the files would be Repair Then Extract if they were par2, or simply Extract if they were rar's. However, what if you wanted to accomodate the situation where you grab all of the files (.nfo, .sfv, .rar's, .par2's, etc.) for drag and drop them to a different destination, with the objective being to Move or Copy the files, in a queued manner. Because you included nfo, sfv, etc files along with the par2 and rar files, the first <CommandGroup> would not be chosen because there were files that did not fit its list of extensions, therefore the second <CommandGroup> would be tested. SInce it accepts all files, it would be the one chosen to execute (in the default case this is a Move <Task>).

Each <CommandTask> subtag under the <CommandGroup> represents an ordered extensions filter for the file list. So if two <CommandTask>s had overlapping extensions, the one first would be chosen to process that file.