Authors CurseForge

Quote from kolie »

The client on curseforge does work, you may have to download it a few times though. What is WoWInterfaces "latest updates" and "favorites".

Quote from Elkano »

well, simply changing only the author to ck is also a bad idea... simply compare the code the SML-1.0 and you'll see what he did. So at least some sort of "based on SML-1.0 by Elkano" should be included I think.

Quote from Elkano »

no, it is intentional that the DO can handle the tooltip in order to allow interactive and custom tooltip frames.
examples would be a frame showing the armor man or DOs from FactionsFu/FriendsFu/GuildFu that allow interaction with the data shown.

function defaultOnEnter(displayFrame, ...)
 if (type(displayFrame.dataObject.tooltip) == "function") then
   GameTooltip:ClearAllPoints()
   GameTooltip:SetOwner(displayFrame)
   displayFrame.dataObject.tooltip(GameTooltip, ...)
 elseif (type(displayFrame.dataObject.tooltip) == "text") then
   GameTooltip:ClearAllPoints()
   GameTooltip:SetOwner(displayFrame)
   GameTooltip:SetText(displayFrame.dataObject.tooltip)
 end
end
Displayer:SetScript("OnEnter", dataObject.onEnter or defaultOnEnter)

Quote from Industrial »

Libraries shouldn't have tocs.

Quote from Funkydude »

I want to try use LibDataBroker in statblocks but at the moment not sure the best route to take, the problem is every block has a strict dependancy on the core to provide it's prototype functions for block options, e.g. :Lock :GetX :GetY to cut down on the amount of code in blocks, also they each have separate config tables as they each have different options that they inject into the core. This I guess could be changable to a standalone config per block (with the requirement of aceconfig ofcourse) but that doesn't change the fact that the config is calling functions only existant in the statblocks core.

Now if I understand this right, if I want to use LibDataBroker the blocks need to be neutral so that the user can choose what core they wanted? I'm really not sure how best to go about that without adding full functions to every block's config. Basically removing the dependancy on the core, but replicating the code in the blocks, but again this would put a dependancy on aceconfig, some advice? ;p

Quote from Borlox »

Imagine a data object without .text and .icon. How should it be displayed?
But the spec could be changed that a data object must provide at least either .text or .icon. A display addon needs something that can be displayed.

Quote from Elsia »

<snip>don't feel like parsing atm</snip>
A last thing that I'm missing is data allowing to push to the display somehow. Say if you want to display a clock or DPS and want periodic update. That's different than static text that just pops up. Clearly you'd want the data to decide when the display needs to be informed about updates (though the display may choose to modify or ignore it).

Quote from Kagaro »

LibDataBroker-1.0 needs a little more work imho before we start making a lot of plugins for it.

1.) Enforce required attrbiutes.
2.) Creation with a base set of attributes
3.) Namespace collsion enforcement.
4.) Consistent callback events

Granted this is just my 2 cents, here is the pasty for modifed version http://ace.pastey.net/85675

All it adds is a few error calls on invalid data, and creation with a set of attributes. I added the error to the RegisterObject, cause even the test cases fail to check the return value to make sure the object actually registered. Namespace collisions ftl.

Also as you can see I changed the register, and atrbiute changes messages. Since you add the callback for this lib, prefixing with LibDataBroker seemed un-needed. Same for Attribute changed, you get the name, key and value that changed, so there is no need for creating a new 'event' for each registered object.. all it ended up doing was causing people to ignore the name anyways

Im sure we need to go over it a little more and really flesh out failure points, error conditions that need checked. Also why was CallbackHandler removed from the externals without creating a dummy stub of some type? Also why do the Name_Attrbiute for custom attributes? Again this seems unnecessary and going to end up being totally un-used or is every display mod going to have to build custom strings every time to see if some attribute is there OR we end up having dataobjects crafted specifically for a display mod via custom attrbiutes?

Quote from andreasg »

I removed CallbackHandler from the lib, but added it to all the addons using the lib. CallbackHandler shouldn't be inside the libraries, but included in the addons that uses libs that need it right?

Quote from tekkub »

Agreed. Then all the "quick launch" bullshit can have their own nice place, like say Auctioneer's SlideBar. But then, with 2.4 config panel, I see no need for 99% of the quicklaunch buttons now.

Quote from Mikk »

Would it make sense to be able to indicate what KIND of datablock it is?
I.e. does it actually show data, or is it just a command access icon?

Separating the two would make sense to me.