This is a consolidated list of the announced (and sometimes observed) changes in the User Interface API's and functionality for the 2.1.0 release. Please note that this thread is to discuss the upcoming changes and any clarifications or features that are a direct result of those changes, or things which we've been asked to remind slouken of.

IMPORTANT: Off-topic or entirely redundant posts are liable to get deleted. It is however in everyone's best interest to not post them in the first place - We'd rather slouken could spend his time coding us cool things than moderating this thread!

Highlights
* The UI memory limit has been removed, and memory profiling features are available.
* CPU profiling features are available (but must be enabled).
* Conditionals on #show and #showtooltip
* Improved interface loading time and reduced script memory usage by about 50%

Template Handlers
* Script handlers inherited from templates now share a single instance of the handler function, rather than a different closure for each one. This significantly reduces loading time and memory footprint of any frame that's using template handlers (but may behave unexpectedly if you use setfenv on handlers today).

Memory Profiling
* Script memory is now tracked on a per-addon basis, with functions provided to analyze and query usage.
* The script memory manager has been optimized and the garbage collection tuned so there is no longer any need for a hard cap on the amount of UI memory available.
* NEW - UpdateAddOnMemoryUsage() - Scan through memory profiling data and update the per-addon statistics
* NEW - usedKB = GetAddOnMemoryUsage(index or "name") - query an addon's memory use (in K, precision to 1 byte) - This returns a cached value calculated by UpdateAddOnMemoryUsage().

CPU Profiling
* CPU profiling is disabled by default since it has some overhead. CPU profiling is controlled by the scriptProfile cvar, which persists across sessions, and takes effect after a UI reload.
* When profiling is enabled, you can use the following functions to retrieve CPU usage statistics. Times are in seconds with about-a-microsecond precision:
* NEW - time = GetScriptCPUUsage() - Returns the total timeused by the scripting system
* NEW - UpdateAddOnCPUUsage() - Scan through the profiling data and update the per-addon statistics
* NEW - time = GetAddOnCPUUsage(index or \"name\") - Returns the total time used by the specified AddOn. This returns a cached value calculated by UpdateAddOnCPUUsage().
* NEW - time, count = GetFunctionCPUUsage(function[, includeSubroutines]) - Returns the time used and number of times the specified function was called. If 'includeSubroutines' is true or omitted, the time includes both the time spent in the function and subroutines called by the function. If it is false, then time is only the time actually spent by the code in the function itself.
* NEW - time, count = GetFrameCPUUsage(frame[, includeChildren]) - Returns the time used and number of function calls of any of the frame's script handlers. If 'includeChildren' is true or omitted, the time and call count will include the handlers for all of the frame's children as well.
* NEW - time, count = GetEventCPUUsage(["event"]) - Returns the time used and number of times the specified event has been triggered. If 'event' is omitted, the time and count will be totals across all events.
* NEW - ResetCPUUsage() - Reset all CPU profiling statistics to zero.

(continued...)

[ Post edited by Iriel ]

---

UI and Macros Forum MVP - Understand GC!

Added general support for macro option conditionals driving state headers..

For example, the existing state driver template code reduces to:

function SecureStateDriver_OnLoad(self)
 RegisterStateDriver(self, "shift", "[modifier:shift] 1; 0");
 RegisterStateDriver(self, "ctrl", "[modifier:ctrl] 1; 0");
 RegisterStateDriver(self, "alt", "[modifier:alt] 1; 0");
 RegisterStateDriver(self, "actionbar", "[actionbar:1] 1; [actionbar:2] 2; [actionbar:3] 3; [actionbar:4] 4; [actionbar:5] 5; [actionbar:6] 6; 0");
 RegisterStateDriver(self, "stance", "[stance:1] 1; [stance:2] 2; [stance:3] 3; [stance:4] 4; [stance:5] 5; [stance:6] 6; [stance:7] 7; 0");
 RegisterStateDriver(self, "stealth", "[stealth] 1; 0");
end

Lua errors are no longer shown by default, but you can set the scriptErrors cvar to 1 to enable them. It is recommended that AddOn authors and testers leave this turned on so you can catch problems in your AddOns.

This is implemented by code in the _ERRORMESSAGE() function, so if you already have an improved error message AddOn, this will not affect you.

We thought about it, but figured anyone savvy enough to do something useful with the errors is savvy enough to set a cvar:
/console scriptErrors 1

In 2.1 unsolicited whispers will be throttled in an attempt to reduce spam and advertisements. The actual throttling rate is still being tuned, but it won't affect normal play. It will however, affect addons which are using whispers for communication.

So... in 2.1 SendAddonMessage() can use the "WHISPER" chat type for targeted communication:
SendAddonMessage("prefix", "message" [,"type"] [,"target"])
The whisper throttling does not apply to addon communication.

Quit reading our meeting notes. :)

Set*CompareItem() has been removed in favor of the new SetHyperlinkCompareItem()
See GameTooltip_ShowCompareItem() for details.

If you override existing slash commands with your own functions, you should update the new hash table: hash_SlashCmdList

Fixed input and rendering issues with script created scrolling frames.
Setting a frame as the scroll child of a scrolling frame automatically sets the scrolling frame as the parent of the scroll child frame.

Yes, but it also means you don't need to broadcast to the entire party/raid/guild if you want to send targeted info. Hopefully the bandwidth will even out. If not, we can always remove the feature. :)

The test realm is now live, please log in and test your addons. All of the changes listed in Iriel's changes post should be live.

To begin downloading the client and copying your characters (character copies will be available soon) to the PTR realms please visit: http://test.worldofwarcraft.com/ptr/

Yep. :)

Hey Iriel, GetAddOnMemoryUse() should be corrected to GetAddOnMemoryUsage() in your post.

* Improved interface loading time and reduced script memory usage by about 50%

---

Q u o t e:

* UPDATED - name, rank, icon, count, duration, timeLeft = UnitBuff("target", i) -- Now returns duration and timeLeft for buffs you can cast.
* UPDATED - name, rank, icon, count, debuffType, duration, timeLeft = UnitDebuff("target", i); -- Now returns duration and timeLeft in some situations (?need details?).

---

The duration and timeleft are set if they are buffs/debuffs that you cast. The return values are now sorted so your buffs and debuffs are returned in the first indices. (e.g. yours, yours, others, ...)

---

Q u o t e:

Running Before(), then During(), then After() yields
initial 0,0,499.5584
final 999.3247, 1104594.458, 1799.18

which seems to indicate that GetFunctionCPUUsage() and GetScriptCPUUsage() return milliseconds and GetAddOnCPUUsage() returns microseconds.

---

This is fixed for 2.1.0 release. (It's not microseconds, but it was a unit conversion problem.)

Thanks!

Added:
name, itemlink = GetItemGem("name"|"itemlink", index)

This function takes an item with a gem in it and returns the name and item link of the gem at the specified index.
Valid indices are 1, 2, 3

Note that if you specify an item by name, and have multiple items with the same name and different gems, it may pick the wrong one. Using the item link retrieved through some other API is the most effective way to use this function.

You're welcome!

With the upcoming main tank and main assist pullouts in the raid UI, setting the main tank and main assist needs to be protected in the same way targeting is protected. This means that AddOns may not call the function SetPartyAssignment().

However, there is now macro and secure action button support for assigning those roles.

Macro Commands:
/mt <name> - Set the main tank role for the named player, or the current target if not specified
/mtoff <name> - Clear the main tank role for the named player, or the current target if not specified
/clearmt - Clear all main tank roles
/ma <name> - Set the main assist role for the named player, or the current target if not specified
/maoff <name> - Clear the main assit role for the named player, or the current target if not specified
/clearma - Clear all main assist roles

Secure Action Buttons:
type = "maintank" or "mainassist"
action = "set" or "clear" or "toggle"

---

Q u o t e:
Will there be unit ids for the main tank or main assist?

---

Not at the moment. Any raid member can be either a main tank or main assist. When their role changes there is a raid roster update so raid frames can reconfigure themselves.

Frame alpha is inherited from parent frames, the same way scale does.
NEW: alpha = Frame:GetEffectiveAlpha()

This means that you can safely fade the entire UI, e.g.
UIParent:SetAlpha(0.5)

---

Q u o t e:
Does the memory profiling take into account the "owner" of a saved variable? I was thinking that one of the ways to reduce misplaced blame would be always to attribute memory usage in a saved variable to the mod that created it.

---

Yes, the memory for saved variables is associated with the addon that loads them.

---

Q u o t e:
Slouken, on the "maintank" and "mainassist" roles, can players do anything with them other than assign roles? ie, assist the "mainassist" or target the "maintank"?

---

Well, there's not a one to one relationship. Any number of raid members can have the main tank or main assist role.

Yes, potentially. Not for 2.1 though, it's in final bugfix and testing mode.

Added maintank1-40, mainassist1-40 as queryable unit ids.
Added:
count = GetNumPartyAssignments("MAINTANK" or "MAINASSIST")
unitid = GetPartyAssignment("MAINTANK" or "MAINASSIST", index)

This allows you to do things like:
/assist maintank1

Note that you do not get currently get events for these unit ids, so you'll need to map them to raidN or player/partyN if you want to watch events for them.

That's correct.

Yes, it's RAID_ROSTER_UPDATE

Some concern was brought up as to whether having maintankN would be confusing, since there really isn't any guarantee which unit gets which maintank id. There isn't any ordering inherent in the feature, each player may or may not be flagged for the main tank role.

Is there actually a need for maintankN aliases? The raid header templates work just fine without them.

Thoughts?

Okay, after lots of feedback, I'll be pulling the main tank / main assist unit ids, since the ordering (or lack thereof) is vary confusing for organizing raid tactics. The feature is still useful from a UI perspective, just not from a macro perspective, where the unit ids would really be used.

Thanks everyone!

Submitting or editing a GM ticket is now a protected action, and may not be done by third party AddOns.

---

Q u o t e:


Is the GM department overwhelmed with SpamSentry tickets?

---

Yes. :)
On the other hand, we're working on a much easier to use method of reporting spam in-game for 2.1.

Edit: I'm deleting the non-technical discussion, please start a new thread if you want to continue discussion.

Maaaybe! :)

SecurePartyHeaderTemplate and SecureRaidGroupHeaderTemplate are now derived from a single template, SecureGroupHeaderTemplate, which can handle raids, groups, and solo play depending on the attributes set:

showRaid = [BOOLEAN] -- true if the header should be shown while in a raid
showParty = [BOOLEAN] -- true if the header should be shown while in a party and not in a raid
showPlayer = [BOOLEAN] -- true if the header should show the player when not in a raid
showSolo = [BOOLEAN] -- true if the header should be shown while not in a group (implies showPlayer)

Similar changes have been made for SecureRaidPetHeaderTemplate, with the addition of SecureGroupPetHeaderTemplate and SecurePartyPetHeaderTemplate

Not a bad idea, I'll add it to the todo list. Although, if you're reporting spam, in 2.1 there will be a right click menu option to easily and quickly report them.

Here are the new spam reporting API functions for 2.1:
* CanComplainChat(lineID) - determines if we should show the menu for reporting a line of chat spam
* ComplainChat(lineID) - complains about a particular line of chat spam
* CanComplainInboxItem(index) - determines if we should show the “report spam” button on a mail item
* ComplainInboxItem(index) - complains about a particular mail item

Currently AddOns may use these APIs, but if there are too many false reports then these functions may be restricted. So choose wisely. :)

It comes from the player: link in the chat line. See the 2.1 UI files for details.

Just a reminder, chat throttling applies to unsolicited whispers. Using the new "WHISPER" type in SendAddonMessage() is not throttled.

The client is limited in total bandwidth however, to avoid flodding.