Description

Class Colors allows you to change class colors without breaking the Blizzard UI.

Please use the ticket tracker to report specific bugs or request specific additions/changes. General comments, questions, and suggestions should be posted in the forum thread.

The Problem

Addons like !ReTeal change the RAID_CLASS_COLORS table, which is originally created by Blizzard code. Doing so causes all other Blizzard code which reads from RAID_CLASS_COLORS to become "tainted", and Blizzard's restrictions on "secure" code cause certain parts of the UI to stop working. Some examples of problems caused by tainting RAID_CLASS_COLORS include being unable to view the raid panel while in combat, and being unable to set main tanks and main assists from the right-click menu in the raid panel.

The Solution

Class Colors solves this problem by not touching RAID_CLASS_COLORS at all. Instead, it creates its own separate table called CUSTOM_CLASS_COLORS. Since this table isn't created by Blizzard code, and isn't used by any Blizzard code, it doesn't taint anything, and its values can be changed as much as you like. However, this does mean that any addons that read colors from RAID_CLASS_COLORS must be updated to read from CUSTOM_CLASS_COLORS instead (if it exists).

In addition to solving the taint problem, Class Colors also provides an in-game UI for changing class colors. It also applies your custom colors to the Blizzard UI in a safe way that doesn't taint it. To access the configuration UI, type "/classcolors" or open the Blizzard Interface Options window, select the AddOns tab, and select the "Class Colors" entry in the left-hand column.

For Addon Authors

Supporting this system is as easy as checking for the existence of a global table CUSTOM_CLASS_COLORS and reading from it instead of RAID_CLASS_COLORS if it exists.

If your addon creates a local cache of class colors, it is recommended that you also register for a callback when class colors are changed by the user (see API documentation below) and update your color cache when the callback is fired.

As not all users are on systems which load addon folders in alphabetical order, there is no guarantee that !ClassColors will be loaded before your addon naturally. There are two ways you can account for this possibility.

• Ideally, you should delay using any class colors until the PLAYER_LOGIN event; if this is not possible, you could just build your cache from RAID_CLASS_COLORS if CUSTOM_CLASS_COLORS is not yet available when your addon loads, and then update your cache and register for callbacks on PLAYER_LOGIN.

• Alternatively, you can add !ClassColors to your addon's OptionalDependencies, though this is not the recommended solution, as it will prohibit other implementations of CUSTOM_CLASS_COLORS and clutter up your TOC.

API Documentation

The following methods are defined on the CUSTOM_CLASS_COLORS table. They are defined using a metatable __index, so pairs() can still be used to iterate over CUSTOM_CLASS_COLORS without requiring extra code to filter out function values.

:RegisterCallback(method[, handler])

• method - function or string
• handler - table containing function value 'method' (required if 'method' is a string, ignored if 'method' is a function)

• Registers a function to be called when class colors are changed.
• If method is a function, that function will be called with no arguments.
• If method is a string, handler is a table, and handler[method] is a function, handler[method] will be called with handler as the first argument.
• If the function is already registered, nothing will happen.

:UnregisterCallback(method[, handler])

• method - function or string
• handler - table containing function value 'method' (required if 'method' is a string, ignored if 'method' is a function)

• Removes a function from the callback registry.
• If the function is not registered, nothing will happen.

Implementation Details

Class Colors is built on a proposed community standard for a global table of alternate class colors that can be freely modified without tainting anything. This means that addons must explicitly support this standard (see below for details). Class Colors is only one possible implementation of this standard. Any implementation must provide the following:

• Create and populate a global table CUSTOM_CLASS_COLORS with the same keys and value structure as RAID_CLASS_COLORS
• Define methods :RegisterCallback, and :UnregisterCallback on the CUSTOM_CLASS_COLORS table (see API documentation above), using a metatable __index so that people can still iterate over the table using pairs() without having to work around function values

The following are highly recommended, and generally expected, but won't technically break anything if they aren't provided:

• Provide a facility by which users may change class colors
• Store changed class colors between sessions
• Maintain a registry of functions requesting callbacks when class colors are changed, and call those functions when appropriate (see API documentation above)
• Apply user-defined class colors to the Blizzard UI