I've moved this into the developer chat thread as this conversation is going to lead down a path that's way outside of the scope of suggestions ~smile~
In any event, the nUI plugins directory is specifically for built-in plugins as there's no way for WoW or nUI to detect mods that are added down the tree unfortunately. What the plugins directory does is allow me to keep my own addons to nUI separate from the core code as well as allowing me to move third party plugins directly into nUI with minimal fuss if I decide to make one or more of them part of the core distribution over time. So you would start with a base mod like any other mod that installs into the [
Interface > AddOns ] directory.
I do expect that most authors would not go down the path of developing directly for nUI, particularly if they already have an established mod. However, I do strongly suspect that other people are going to want to build things specifically for use with nUI and that's what that API is about... and a big part of that puzzle is performance. One of the reasons why nUI performs as it does is the core engine which would allow other authors to take advantage of that without adding extra load to the game engine. It also allows authors to access most combat related data without having to code for the events and so on... both of which are things that in time I hope will compel some authors to take advantage of the nUI API.
Anyway, Now... as far as learning the API... it kind of starts with what it is you're out to do. I have heavily documented my code, so that's really the starting point.
The best file to look at as far as learning how to create an information panel plugin is probably [
Interface > AddOns > nUI > Layouts > Default > InfoPanels > nUI_InfoPanel_CombatLog.lua ] == From there you can look at the
nUI_InfoPanel_Minimap plugin which shows the basis of one written as a standalone plugin to nUI.
From there, the second place to look is [
Interface > AddOns > nUI > Units > nUI_UnitCache.lua ] which fairly (not entirely) accurately details the cache data nUI can and does collect on players and mobs.
After that the conversation really starts to diverge and I really need to write a document to explain the API, but thats kinda not at the top of the priority list, so for now we can kind of go back and forth here and I'll answer your questions... in time that will probably form the basis of the document ~lol~
Some other key files to look at probably are [
Interface > AddOns > nUI > Units > nUI_UnitPanels.lua ] which will show you how nUI can read the tables in [
Interface > AddOns > nUI > Layouts > Default > UnitPanels {unit mode} > nUI_UnitPanel_{mode}.lua ] to create the panels and then use the skin files to call [
Interface > AddOns > nUI > Units > nUI_Unit.lua ] to create the individual units for the panel.
The latter module pretty much just creates instances of the various unit modules and that's the core of what makes nUI work. If you look, for example, at [
Interface > AddOns > nUI > Units > nUI_UnitLabel.lua ] which is one of the simpler modules, you'll see a method in there function
nUI_Unit:registerLabelCallback( unit_id, callback ) -- if your mod, for example, needed to know that name of the player's current target, you would add a method to your mod and register it with nUI like this...
Code:
local myMod = CreateFrame( "Frame", "myMod", UIParent );
local targetInfo;
local totInfo;
myMod.newUnitInfo = function( unit_id, unit_info )
{
if UnitIsUnit( unit_id, "target" ) then
targetInfo = unit_info;
if not unit_info then print( "you don't have a target anymore" );
else print( "your target is now "..unit_info.name );
end
elseif UnitIsUnit( unit_id, "targettarget" ) then
totInfo = unit_info;
if targetInfo then
if not unit_info then print( "your target doesn't have a target anymore" );
else print( "your target's target is now "..unit_info.name );
end
end
end
}
nUI_Unit:registerLabelCallback( "target", myMod );
nUI_Unit:registerLabelCallback( "targettarget", myMod );
In this somewhat simple example, the mod doesn't have to worry about events at all. It doesn't need to worry about whether not the player changed targets or any other similar situation. nUI will track the name of the "target" and "targettarget" units and alert your mod when the name changes or when the unit no longer exists (it passes a nil value for "unit_info" when the unit no longer exists).
So, using this API, nUI plugins are entirely free of worrying about the game engine or data monitoring and collection. Just register your mod with the modules that produce the data you care about and nUI deals with all of the rest.
The benefit in this is that there's only one mod that is watching for changes in the units and when a change that a plugin cares about occurs, nUI can then alert them all and pass the data to them pre-collected. This also means that nUI only has to "read" the data once when it changes and then can pass that to any number of waiting UI elements.
The best example is the player unit frame health bar (nUI_UnitHealth.lua) -- There are player unit frame bars in all seven unit frame panels, plus all three HUDs... so there are ten player unit frame bars in nUI, but when there's a player health update, nUI only asks Bliz for the player's health once, then just passes that data to the ten waiting health bars.
Follow?
nUI API
Hybrid Mode
