JMRI: DecoderPro User Guide
Create a Custom Programmer
How do I create my own custom programmer?
The answer starts with the creation of an xml file in the "programmers" subdirectory of
the JMRI distribution. The contents of the file are described here.
After some initial parts (which you can just copy from an existing file), the rest of the
file is a series of "pane" definition elements. Each one become a pane in the DecoderPro
window.
The panes in the programmer file appear when you select that programmer in DecoderPro.
Note that panes can also be defined in the decoder definition, in which case those panes
appear after the ones in the programmer definitions.
- There is an option to present/hide panes from the decoder file. If you're writing a
very basic programmer, you might want to hide them to keep the interface simple.
- If a pane is defined in the decoder file and programmer file with the same name, the
one from the decoder file (the more specific one) appears.
- Specifying items to display
-
The basic element of a programmer pane is a "display". This tells the programmer to
present a single variable. The attributes are:
- name - (Required) This is the "standard name" of the variable to be
presented.
- label - If present, this will be used to label the variable on the pane
instead of the name or standard name of the variable.
- layout - Where to locate the label with respect to the editable field,
e.g. the text box. Possible values are "left", "above", "below", "right" with a default
of "right".
- viewOnly - Present the variable but do not allow the user to change
its value in this place. Possible values are "yes" or "no", with a default of "no".
-
format -
How the variable should be presented. Numeric variables can be presented as
- an editable text field, which is the default if nothing is specified
- hslider - a horizontal slider
- vslider - a vertical slider
Enum variables can be presented as
- a selection box, which is the default if nothing is specified
- radiobuttons - Each possible value is presented as an individual
button
- checkbox - An enum with only two states can also be presented as a
checkbox
- offradiobutton - A single button that sets the 0 choice for the
variable when selected
- onradiobutton - A single button that sets the 1 choice for the
variable when selected
These last two can be useful for indicating which parts of a configuration are
active; see the "Speed Table" pane of Comprehensive.xml for an example.
-
tooltip - Allows you to specify a default tooltip to be presented when the
cursor is left over the variable. This tooltip will be overridden by any tooltip
defined in the decoder file. (Note: This behaviour differs from the behaviour of the label attribute.)
Which name to display is controlled by the pane's 'nameFmt' attribute,
and the 'label' attribute on each display element (variable).
The choices are:
- If a label is specified, it will be used. Use a label if you want absolute control
over what a variable should be called, regardless of what the decoder file calls it,
and you don't like the standard name.
- The pane's nameFmt attribute is "item", in which case the item name will be used
regardless of what the decoder file calls the variable. Use this is you want a uniform
appearance for the pane for all decoders. But be aware that some standard names are
really so generic as to be useless.
- If the pane's nameFmt attribute is allowed to default, or contains "mfg", the
decoder definition file's name will be used. This is the normal form, as it allows a
manufacturer to specify in some detail what a variable defines.
- Formatting
-
Each pane of the programmer consists of (nested) rows and/or columns. Columns lay out
variables from top to bottom. Rows lay out variables from left to right. You can nest
these to achieve various effects; for an example of this, see the "Speed Table" pane of
the Comprehensive.xml file. It has two columns; the left of each uses a row to put some
sliders from left to right.
- Special Elements
-
There are a number of elements you can use to get the programmer formatted exactly the
way you want:
-
grid - Create a grid for laying out elements in aligned rows and columns.
See the Grid Layout section below.
- label - Add text to a pane.
- soundlabel - Add a soundlabel (from the decoder definition file) to a
pane. It has a one attribute:
-
- num - (Required) This is the number of the sound label to be
presented.
- separator - Add a separator line to a pane. If included in a column,
this will be a horizontal separator line. If included in a row, it will be a vertical
line.
- cvtable - Insert a table of CV values onto the pane. To get the spacing
right you should probably not combine this with other variables on the same pane.
-
fnmapping - Show a function mapping grid. This requires variables with
specific names, which are described on a separate page.
- dccaddress - Show a combined variable for the DCC address. This consists
of a checkbox that selects use of short vs long address, and a single text field for
entering the address. Depending on how the checkbox is set, the text field will
configure the CV1 short address or the CV17/18 long address.
- Formatting with the Grid Layout
-
The "row" and "column" elements allow you to align elements in rows or columns, but if
you have multiple columns within a row element (or vice versa) it is not possible to
ensure that rows in adjacent columns (or vice versa) stay aligned.
The Grid Layout allows you to align elements in rows and columns, maintaining alignment
even if a particular element is absent. There are two elements:
- grid - Create a grid layout (within a "row" or "column" element):
-
- It may have one or more optional attributes.
- The only allowed sub-element is "griditem" and there must be at least one of
these.
- griditem - Create a grid item (within a "grid" element):
-
- It should have "gridx" and "gridy" attributes.
- It may also have one or more optional attributes.
- It must contain one or more elements, which can be any combination of any of
the other elements listed above, including "row", "column", or even another
"grid".
The "gridx" and "gridy" attributes of a grid item specify the location of that item
within the grid. A value of gridx="0" puts the item in the leftmost column. A value of
gridy="0" puts the item in the topmost row. Other attributes to control the format of the
grid items are available and are documented in the Java® GridBagLayout Tutorial.
- Attributes of "grid" apply to all items in the table.
- Attributes of "griditem" apply to only that item and override any equivalent
attribute of "grid".
- Both numeric and named constant values (as specified by the documentation) can be used.
- Two extra named constant values are available for "gridx" and "gridy":
-
- "CURRENT" is the value from the last added "griditem" (i.e. the same row or
column).
- "NEXT" is one more than the value from the last added "griditem" (i.e. the next
row or column).
("NEXT" is actually a synonym for "RELATIVE".)
- The "insets" attribute is specified as insets="top,left,bottom,right" where "top"
etc. are integers.
- A "griditem" can span more than one grid cell. Attributes "gridwidth" and
"gridheight" control this.
- By default grid items clump together in the centre of a container. Attribute
"weightx" can override this and left/right justify.
- It is possible in some circumstances to omit either or both of "gridx" and "gridy"
from a "griditem" and specify a default value in "grid". See xml/decoders/esu/v4fnOutPane.xml for an example of this usage to generate
a simple single-column right-aligned grid. (However if you are not careful with use of
this technique and/or the "RELATIVE" constant, results can be bizarre.)
- Unfortunately "ipadx", "ipady" and "insets" allocate space even if the enclosed
display variable(s) fail qualification. A workaround is to qualify the whole "griditem"
enclosing the variable (if that is appropriate to the situation).
For an example of Grid Layout use (with some explanations of attributes used), see
xml/decoders/esu/v4soundPane.xml. The LokSound Select (and V4)
definitions use this file.
- Installing your new programmer
-
All of the .xml files in the "programmers" subdirectory will appear in the selection
box when you create a new programmer in DecoderPro. To use your new file, just put it in
the "programmers" subdirectory of the "prefs" directory and select it. You don't have to
restart the program, as the list is remade each time you open a new programmer
window.
How variables in a decoder file match up with the programmer file
Each decoder file defines
variables that describe
specific controls within the decoder. The programmer file then describes how to place those
on panes so that the user can find and manipulate them.
Each "display" element in the programmer file defines one thing to show. But which one?
That's controlled by the "name" attribute of the "display" element. DecoderPro takes that
"name" and looks through the decoder definition for a "variable" element that has either the
same "item" or "label" attribute.
This has some nice effects:
- The "name" in the "display" element is effectively a "standard name", that can be used
in decoder definition files from different manufacturers. Since this is separate from
the "label" on the decoder variable, it's possible to have a generic programmer file that
works for many types of different decoders, while still displaying specific variable names.
For more on this, please see above.
- It lets you use very generic names to control where somewhat different things go. For
example, different sound decoders provide different controls. One might have "Airpump",
while another doesn't have that at all, and instead has "Brake Squeal". We don't want to
have the programmer files contain zillions of "display" elements to handle every possible
option. Instead, we use elements with more generic names, like "Sound Option 1", for the
display name.
The decoder definition then has a "label" of "Airpump" or whatever, and an "item" of
"Sound Option 1". Everything matches up properly, and "Airpump" appears on the computer's
screen.
