The back story: large parts of the Bliz UI cannot be functionally modified due to tainting issues. Their behavior can be apparently modified by hiding the stock elements and supplying replacements, but this approach is not satisfying to me.
Now, I know that the devs are in favor of good code, but the're also busy, frequently with cool new features. So, I've set out on a project to gradually update the FrameXML code, especially using secure templates and attributes for secure behavior whenever possible, to make the UI code as moddable as possible. It is my hope that this work will make it easier for the devs to rapidly incorporate robust, highly functional code into the stock UI.
Step one does some foundation work on the secure templates and tackles the main action bar.
Visible Changes: The slide animation for going into and out of Shadowform and Stealth has disappeared. It does not require secure functions and could be replaced, but it was giving me a headache and I wanted to get a proof of concept out. All other visible changes in the behavior of the UI as a result of this code are unintended and should be addressed.
API Changes: While no changes to the API are REQUIRED for this update, allowing ChangeActionBarPage to accept values outside 1-6 will allow some of the new function to reach their full potential.
Functional changes:
Secure Action Buttons and related templates now support states on most attributes, if the corresponding "checkstate-<attributename>" attribute is set. A frame's state can be defined from an internal 'state' integer/string attribute (for conventional stateheaders and multi-inheritance), from a 'stateheader' attribute referring to a frame (for detached headers) or through 'useparent-state'. State does not support modifiers or buttons. Calls wishing to use SecureButton_GetModifiedAttribute without parsing the attribute for state can supply the boolean value false (NOT nil) anywhere after the button parameter (fourth, fifth, or sixth parameter).
State-sensitive attributes can be stored as tables of [state] = value pairs, for circumstances where separator characters need to be used in attribute contents. (This will probably be removed.)
Action Bar Buttons have been rewritten to use parameters rather than globals (self > this) as much as possible.
Action Bar Buttons now use an actionoffset attribute (usually inherited from the parent action bar) to determine what their ID should be added to for ActionButton_GetPagedID(). This is used in the hope that ChangeActionBarPage() will eventually accept values outside 1-6, for use with smaller bars that support more pages (for instance 12 pages of eight slots each with three reserved for stances). Note, however, that the stock bar does not support pages greater than 6; my expectation is that it will go blank in these cases.
The MultiActionBars have been rewritten to use these attributes with vastly simplified templates.
The main actionbar buttons are now children of a state header that sets their page according to current page and stance automatically.
Action buttons now update their appearances whenever one of several attributes that can define their behavior change.
Bindings for the action bars are now CLICK bindings. A glue function has been added to make sure these bindings recover the keys bound to the old ACTIONBUTTON scripts.
The supplied files are derived from a fairly recent PTR build (7175 I believe)
Changed Files list:
ActionBarFrame.xml
ActionButton.lua
Bindings.xml
BonusActionBarFrame.lua
MultiActionBars.lua
MultiActionBars.xml
SecureStateHeader.lua
SecureTemplates.lua
Comments and feedback are gratefully appreciated, preferably in this Blizzard thread:
http://forums.worldofwarcraft.com/th...12518674&sid=1.
Linear Mode
