LDBIcon is a Lib in it's own right. The minimap icon is controled by the addon itself as part of it's interaction with LDBIcon. So LDB itself is not being told to hide or show the plugin, but the lib is doing it. LDBIcon is unique in that sense.
Yeah, indeed. Preferrably it would be a "show/hide" field rather than "enable/disable". The display should not delete settings for the feed.
main reason this sort of thing wasnt in the origional design is that a user could use several LDB display's (Granted it's not likely). But one could use a minimap style display such as LDBIcon and Bazooka (as i do in SOCD).
The problem happens when you enable the feed, what display should enable?
Mainly because they all display different tooltip info, which may very well be too much to fit in a single tooltip, not to mention annoying to read. I also prefer for them to have their own proper icons (and labels).
then tell the user to go to the display's settings to disable them :)
I've no idea if this is way off as far as design goes, but would some kind of toggle control, to tell displays to show/enable or hide/disable your feed, be reasonable? I have more than one feed in my addon, and they're displayed based on settings. Merging them into a single feed won't be pretty in my case.
Been talked about on occasion, but the response always seems to be that it's a display issue and should be handled by the display.
phanx i do agree mostly with that idea with .label & .text
however how does .value play into this?
is .label & .value mutually exclusive with .text?
The display i use treats them (label and text) the same ignoring the .value most of the time. I've got mixed reports about it's usage in other display addons when using .text and .label, in all my addons that have LDB i've stayed away from .label or .value for the most part and just use .text as it will always get the job done.
yes but is that used instead of .text or with .text?
.text is required according to the sepc, so how does it get treated?
I say, because i don't know of any ldb display that treats it the same way, xpt that if i only set a .text i get a consistent display for all of them. with .label some times it shows up others it's not there w/o extra magic.
As far as I (and many other folks) am concerned, "label" is just that - the label for the icon: I see a gold coin icon. What is it? Turn on labels, and I see "Broker_Currency". The "text" field is the actual data. How this can be confusing is beyond me.
If we make a new spec, we have to go through all the stuff again: does label mean this or this , what does text in this spec mean...
Beauty of making your own spec, is that you actually get to decide what that is. The main reason that the default "data source" spec is so f'ed up in that regard is that no one has "claimed ownership" of it. The only one who really could isn't/hasn't claim'ed it or given an answer.
what should happen is the displays should use more generic functions for each data spec that way when a new one like this comes along adding support isn't a code rewrite. Then it won't matter if we extend a spec or add a new one.
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.
ldb.secure[Method] = string
where the string is the arg sent to frame:SetAttribute(method, string)
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
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.
1. What is the tag policy #X-Embeds: and #OptionalDeps: tags for LibDataBroker-1.1?
2. What is the embedding policy for addons nolib version?
#X-Embeds is not used anymore, it is depreciated
#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.