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)
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"
}
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.
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.
local function Callback(this, event, item)
print(item, "was selected.")
end
local myDropDown = AceGUI:Create("DropDown")
-- ...
myDropDown:SetCallback("OnValueChanged", Callback)
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")
0
Thanks in advance!
0
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)
0
Thanks very much!
0
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
0
How about something like this:
A basic broker looks has the following form:
The specs show what sort of information the broker is offering. They could be for example:
Some fields of the specs may be optional.
A clock broker would be something like this:
A launcher would be
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.
0
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:
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).
0
0
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.
0
Sorry, I'm in a spammy mood today.
0
The OnValueChanged way would look like this:
0
I opened a ticket with a patch that adds a DropDown:GetValue() function, that may be a better way for some addons.
0
widget_object == widget_object.frame.obj
So you could do the following:
0
0
0