Authors CurseForge

The German 10€ cards could need a little restock :)

Thanks in advance!

I think that's a good idea.

How about adding a commit hook, to inform authors that still have Ace2 referenced in their .pkgmeta/svn:externals? (I'm not sure whether it's possible to just show a message without cancelling the commit)

At least the Amazon.de 10€ cards are back in the store.

Thanks very much!

Another site:
http://drantum.bplaced.net/joomla/downloads/cat_view/38-addons-313.html

It's a German page with a small selection of outdated addons. There's a contact page:
http://drantum.bplaced.net/joomla/kontakt.html

Somebody had the idea of a comma separated list of specs (I can't find the post at the moment), I think that quite a good idea.

How about something like this:

A basic broker looks has the following form:

{
    type = "extended", -- or something else, just for compatibility
    specs = <string>, -- comma separated list of specs
  
    label = <string>, -- I think every broker could use a label
}

The specs show what sort of information the broker is offering. They could be for example:

text = {
    text = <string>,
}

value = {
    value = <string>,
    suffix = <string>,
}

tooltip = {
    OnEnter = <function ()>,
    OnLeave = <function ()>,
        
    tooltip = <frame>,

    tooltiptext = <string>,
    
    OnTooltipShow = <function (tooltip)>,
}

range = {
    min = <number>,
    max = <number>,
    value = <numer>,
}

icon = {
    icon = <string>,
    
    iconR = <number>,
    iconB = <number>,
    iconG = <number>,
    iconCoords = <table>,
}

action = {
    OnClick = <function (button)>,
}

Some fields of the specs may be optional.

A clock broker would be something like this:

clock = {
    type = "extended",
    specs = "text,icon",
    label = "ExampleClock",

    text = "00:00",

    icon = "Path\\To\\Clock\\Image"
}

A launcher would be

myLauncher = {
    type = "extended",
    specs = "action",
    label = "MyAddonLauncher",

    OnClick = function(btn)
        MyAddon:ShowConfig()
    end,
}

The main advantage of this idea is easy extensibility.

With the old type = "..." system adding something is always the choice between expanding (or bloating) an old type, or creating a new one with the risk of missing something (like tooltips, for the statusbar example).

With specs, something new would be just another spec, that gets implemented by the displays after a while.

There are some disadvantages though.
The spec system misses a clear distinction between what is now called "data source" and "launcher", they would just differ in what specs the use.
And (I think this is the main drawback) it would take some time until all displays and brokers have switched to the new system.
I think, this could be done in a compatible way, supporting the old types for some time but only extend the new system. It would be very important, that all displays make the move to the new system, to allow addon developers to support it without the problem that some displays don't understand their brokers.

Quote from Partha1

Hmmm, is this thread still alive? Anyway, I have an idea for adding to the spec which I think could be quite useful for many things.

How about a Status Bar?

Maybe something like this:

Broker.obj = LibStub("LibDataBroker-1.1"):NewDataObject("Broker StatusBar", {
type = "data source",
icon = "Interface\\Icon",
label = "StatusBar",
text = format("%i %%", someValue / maxValue * 100),
barMin = 0,
barMax = 100,
barValue = function() return someValue / maxValue end
barR = 0,
barG = 0,
barB = 1,
} )

Any Comments?

I thinks thats a good idea, but a special "statusbar" type would be more suitable. It has nearly nothing in common with the old "data source".

How about:

{
  type = "statusbar",

  min = <number>, -- minimal value
  max = <number>, -- maximal value
  value = <number>, -- current value

  text = <string>, -- overlay text, optional
  format = <string>, --?? format string suitable for string.format(broker.format, broker.min, broker.max, broker.value), optional
  icon = <string>, -- icon, optional

  colorR = <number>, -- optional
  colorG = <number>, -- optional
  colorB = <number>, -- optional
}

In my opinion the color should be controlled by the display, not by the data broker. Edit: yssaril made a good point about that.

The 'value' field does not need to be a function, the AttributeChanged callback is called whenever the value is changed (that's the key of the LibDataBroker design).

The BannedAddOns.dbc seems to contain the baddons.wcf file (0x0014 to 0x01F7), which is extracted and put into Cache\WDB\<locale>\baddons.wcf at startup.

The newest baddons.wcf (from the current EU PTR Client) only contains "d41d8cd98f0b24e980998ecf8427e" (= md5 of an empty string) for all entries.
I think i was wrong with the last 4 bytes of an entry, these are now 0x0002 for all of them so they don't think they mark the last entry of the file. Maybe it's a version identifier incremented each time an entry is modified (pure speculation).

The unknown 4 bytes are now 0x49347A01 for every but the first and the last entry (which have 0x493479E8 and 0x49347AF9). This is the only thing that has changed comparing to the uploaded BannedAddOns.dbc from yoshimo. This one contains 0x49346BD8 for the first, 0x49346CE9 for the last and 0x49346BF1 for the rest. Maybe it contains a locale id.

function eval(code, ...)
     return loadstring(code)(...)
end

Here you are...

Sorry, I'm in a spammy mood today.

The patch was applied in revision 839.

The OnValueChanged way would look like this:

local function Callback(this, event, item)
  print(item, "was selected.")
end

local myDropDown = AceGUI:Create("DropDown")
-- ...
myDropDown:SetCallback("OnValueChanged", Callback)

At the moment the only clean way is to listen to the OnValueChanged event.

I opened a ticket with a patch that adds a DropDown:GetValue() function, that may be a better way for some addons.

I don't know whether it's a part of the interface, but all for all widgets I know the following is valid:

widget_object == widget_object.frame.obj

So you could do the following:

local direct_frame = acecd:AddToBlizOptions(name-of-my-addon)
lcoal widget = direct_frame.obj

It seems to work now, thank you Nevcairiel and Ackis!

Any update on this? The checkout is still not working...

You could even do it the fancy way using metatables:

local matches = {
    ["%a?hat"] = "Fedora",
}
setmetatable(matches, { __index = function(self, key)
    for k, v in pairs(self) do
        if key:match(k) then
            return v
        end
    end
end})

assert(matches["chat"] == "Fedora")
assert(matches["phat"] == "Fedora")
assert(matches["hat"] == "Fedora")