2. What is the embedding policy for addons nolib version?
What OrionShock said above, plus: Tekkub has stated that LibDataBroker should always be embedded. I don't know why, and I don't ask. However, he has also stated that if people start slapping it into their .pkgmeta as an external that he would remove it from github.
What OrionShock said above, plus: Tekkub has stated that LibDataBroker should always be embedded. I don't know why, and I don't ask. However, he has also stated that if people start slapping it into their .pkgmeta as an external that he would remove it from github.
Thanx, it's realy useful info.
P.S. May be Tekkub will make some LDB docs update on github? Many addons is slapping it into their .pkgmeta as an external.
#X-Embeds is not used anymore, it is depreciated
as for
#OptionalDeps and LDB, none. It should always be included in the addon naturally as another file as well as CBH and loaded along with the libs as usual.
Thanx!
It means, what no one should include LDB in a #OptionalDeps tag and no one should use #X-Embeds tag?
Some offtopic...
1. Where I can get more info about deprecaiting #X-Embeds tag (google don't answer me)?
2. How addons like ACP can check addons dependensies, if #X-Embeds tag is depreciated?
If I remember correctly, X-Embeds was only used by the old WoWAce packager, whereas the current one uses the externals specified in the .pkgmeta. ACP more than likely checks RequiredDeps and OptionalDeps to get its information.
Any "# X-*" headers are customized headers so you will have a hard time finding information about them. I'm not even sure it was used by WowAceUpdater. IIRC it was used to create the addon information frame on the old wiki.
BTW, even if slapped in .pkgmeta, it is still embedded in the no-lib packages because it comes from an external repository (from a wowace POV).
According to the LDB wiki, it is intended for no particular purpose : "Due to its simple generic design, LDB can be used for any design where you wish to have an addon notified of changes to a table."
On the later point, I admit LibSink already does a great job (though nothing forbids LibSink to interact with LDB scroll area DOs or even be rewritten to use them).
LDB is just a proxy table. Proxies have a million uses. LDB uses one to implement "property change events".
The one thing you should steer clear of is using fields as events, ie. setting a field to generate an event which does something. If you use properties, you should not expect an action to occur as the direct result of setting the property.
gathers the data from several sources into a single object. can otherwise behave like a data object.
would need
a field for each external data object giving it a local name.
so an external object called "hitpoints" would be represented as a field "hitpoints", the value of "hitpoints" would be the text property on the external object.
to generate the text field on the multiplexer, a format string with substitution tokens could be used.
textformat = "I have {hitpoints} hitpoints"
would put the text property of the hitpoints data object in place of {hitpoints}
Another type along the same lines: "Multidata Object"
This is essentially the same as the multiplexer, but all the data is local.
I just hope you don't want to change the .toc files for more addons... :rolleyes: (all of your changes I've seen were reverted if I remember well)
Now, I'm totaly banned, But I believe that my changes were true enough (with some exceptions).
Only one my change has been fully reverted (this change has been based on knowledge of how the Curse Client works), all the others have been accepted, some with minor changes.
Then I have tried to find a policy in this area, but it has appeared inconvenient.
And now I'm banned without any private warning.
I promise that I will not make any more such changes without approval of the addons authors.
I ask to excuse me for the supplied inconveniences.
I ask to give me one more chance and to activate my account. :rolleyes:
I'm thinking about how I could apply LDB in my mana monitoring addon.
5 second rule: I could provide time remaining in the 5sr, the one problem is that my update frequency is too high, and I'd want events to fire at a maximum rate even when updating the value continuously. Being able to specify a throttle function would be helpful.
In general i'm finding i like this pattern
DO = {
text = "foo"
data = {
foo = 1
}
formattext = function() text = data.foo end
}
Silly, off-question: How could one implement a secure function from a DO? Put simply, I want a users Hearthstone to cast when they click the object. >.<
Silly, off-question: How could one implement a secure function from a DO? Put simply, I want a users Hearthstone to cast when they click the object. >.<
I wouldn't advise it, special crap has to be done to avoid taint, and I doubt many displays will do it.
I'd just make an onclick function that shows/positions your secure frame (but don't anchor it to the display), and make sure it only works out of combat.
I thought about doing that, but it would end up being more trouble than it's worth since I'd have to constantly check the position of the DO, etc. How about implementing a secure-click data type? :p
I thought about doing that, but it would end up being more trouble than it's worth since I'd have to constantly check the position of the DO, etc. How about implementing a secure-click data type? :p
StormFX, tekk dosn't implement anything, he mostly gripes about people that want something sane.
If you want a secure click functionality, talk to a display author and sane methods of doing this though LDB. Considering a lot of the secure stuff is done with strings, not sure doing this will be a problem.
idea:
ldb.secure[Method] = string
where the string is the arg sent to frame:SetAttribute(method, string)
So::
ldb.secure = true
ldb.securetype = "item"
ldb.secureitem = "hearthstone"
-- &&
function LDB_Update(event, ldb, key, value) --not sure what the signature for ldb's callbacks are--
local method = key:find("^secure(.+)")
if method then
button:SetAttribute(method, value)
end
end
Tho the Display would have to create a button and anchor it to all secure code. That might be more than what some authors are willing to add in for you.
I'm sure a secure data source spec could be made, but it wasn't put in the main spec because secure buttons bring in all sorts of wonderful issues, and the spec is about showing data, not performing actions, especially secure actions.
Personally I think if it requires secure actions, it's better you make your own UI for it.
I believe Funkydude added support to StatBlockCore...
"Block" is the key word here. Creating secure buttons is fine. The problems begin when you want your secure stuff to peacefully co-exist with insecure stuff. For instance, you have a secure button and you anchor it to an insecure one, which also makes it secure (afaik). Guess what happens when that button attempts to let's say change width while in combat, because some event fired that caused it to update its data (let's say text label). Yep, that's right, taint and action blocked. Or you can disallow updates while in combat for plugins that do not have the secure attributes, which is imho kinda harsh and beats the point of using them under all circumstances in the first place. While you can work around these issues when dealing with blocks that you don't really need to "stick" together, problems arise when you want to implement this for a bar addon, unless of course you make everything secure and possibly sacrificing some features in the process (let's say auto showing/hiding on mouseover, while in combat).
That being said, a secure spec certainly has a purpose, it's just (imho) not suitable for all kinds of uses.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorWhat OrionShock said above, plus: Tekkub has stated that LibDataBroker should always be embedded. I don't know why, and I don't ask. However, he has also stated that if people start slapping it into their .pkgmeta as an external that he would remove it from github.
Thanx, it's realy useful info.
P.S. May be Tekkub will make some LDB docs update on github? Many addons is slapping it into their .pkgmeta as an external.
Thanx!
It means, what no one should include LDB in a #OptionalDeps tag and no one should use #X-Embeds tag?
Some offtopic...
1. Where I can get more info about deprecaiting #X-Embeds tag (google don't answer me)?
2. How addons like ACP can check addons dependensies, if #X-Embeds tag is depreciated?
-
View User Profile
-
View Posts
-
Send Message
Project Author-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBTW, even if slapped in .pkgmeta, it is still embedded in the no-lib packages because it comes from an external repository (from a wowace POV).
-
View User Profile
-
View Posts
-
Send Message
Project AuthorInteresting...
I just hope you don't want to change the .toc files for more addons... :rolleyes: (all of your changes I've seen were reverted if I remember well)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI was thinking about making an addon DO, and then making an addon manager as a "display".
One thing that seems clever is having dependancies registered for a change in the "enabled" field, and having them auto-enable along with the addon.
You need x-embeds because you cant access optionialdeps in-game
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLDB is just a proxy table. Proxies have a million uses. LDB uses one to implement "property change events".
The one thing you should steer clear of is using fields as events, ie. setting a field to generate an event which does something. If you use properties, you should not expect an action to occur as the direct result of setting the property.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1) Data Object Multiplexer
gathers the data from several sources into a single object. can otherwise behave like a data object.
would need
a field for each external data object giving it a local name.
so an external object called "hitpoints" would be represented as a field "hitpoints", the value of "hitpoints" would be the text property on the external object.
to generate the text field on the multiplexer, a format string with substitution tokens could be used.
textformat = "I have {hitpoints} hitpoints"
would put the text property of the hitpoints data object in place of {hitpoints}
Another type along the same lines: "Multidata Object"
This is essentially the same as the multiplexer, but all the data is local.
Now, I'm totaly banned, But I believe that my changes were true enough (with some exceptions).
Only one my change has been fully reverted (this change has been based on knowledge of how the Curse Client works), all the others have been accepted, some with minor changes.
Then I have tried to find a policy in this area, but it has appeared inconvenient.
And now I'm banned without any private warning.
I promise that I will not make any more such changes without approval of the addons authors.
I ask to excuse me for the supplied inconveniences.
I ask to give me one more chance and to activate my account. :rolleyes:
Thanks you that you do.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium5 second rule: I could provide time remaining in the 5sr, the one problem is that my update frequency is too high, and I'd want events to fire at a maximum rate even when updating the value continuously. Being able to specify a throttle function would be helpful.
In general i'm finding i like this pattern
DO = { text = "foo" data = { foo = 1 } formattext = function() text = data.foo end }-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI wouldn't advise it, special crap has to be done to avoid taint, and I doubt many displays will do it.
I'd just make an onclick function that shows/positions your secure frame (but don't anchor it to the display), and make sure it only works out of combat.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumStormFX, tekk dosn't implement anything, he mostly gripes about people that want something sane.
If you want a secure click functionality, talk to a display author and sane methods of doing this though LDB. Considering a lot of the secure stuff is done with strings, not sure doing this will be a problem.
idea:
where the string is the arg sent to frame:SetAttribute(method, string)
So::
ldb.secure = true ldb.securetype = "item" ldb.secureitem = "hearthstone" -- && function LDB_Update(event, ldb, key, value) --not sure what the signature for ldb's callbacks are-- local method = key:find("^secure(.+)") if method then button:SetAttribute(method, value) end endTho the Display would have to create a button and anchor it to all secure code. That might be more than what some authors are willing to add in for you.
Personally I think if it requires secure actions, it's better you make your own UI for it.
-
View User Profile
-
View Posts
-
Send Message
Project Author"Block" is the key word here. Creating secure buttons is fine. The problems begin when you want your secure stuff to peacefully co-exist with insecure stuff. For instance, you have a secure button and you anchor it to an insecure one, which also makes it secure (afaik). Guess what happens when that button attempts to let's say change width while in combat, because some event fired that caused it to update its data (let's say text label). Yep, that's right, taint and action blocked. Or you can disallow updates while in combat for plugins that do not have the secure attributes, which is imho kinda harsh and beats the point of using them under all circumstances in the first place. While you can work around these issues when dealing with blocks that you don't really need to "stick" together, problems arise when you want to implement this for a bar addon, unless of course you make everything secure and possibly sacrificing some features in the process (let's say auto showing/hiding on mouseover, while in combat).
That being said, a secure spec certainly has a purpose, it's just (imho) not suitable for all kinds of uses.