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.
And if you think that's bad enough, you are going to love the following "exceptions" :
1) What happens if .launcher is provided but no .label (or .text) and you have an option to display label ? Do you disable the option or revert to the DO name ? (I chose the later). There is no clear guideline.
2) What happens if a DO does not provide .text on load (after registration) but sets .text after let's say a timed event ? (yep it does exist) Answer : You probably need to register a callback anyway :p
3) What about plugins that can "write" to .label and alter it depending on their functionality as stated in the "Extension or Deviations of Data Source and Launcher" ? Again you probably need a callback anyway (I haven't even bothered with this case, as I have no practical experience) to change the .label according to what the DO dictates.
When I was testing the implementation I do remember of at least one case where .text was provided and no .label. And no, it wasn't Prat :p In all honesty, I don't remember which plugin it was (it was surely hosted on WoWI, I do remember that much).
As for the rest, well the open spec is both a blessing and a curse. Blessing because plugin authors have far too many choices (though realistically speaking they will try to implement something that "plays nice" with most if not all displays) and a curse because the display authors need to find a way to provide a consistent display, preferably without being intrusive on the code provided by plugin authors and trust me it's not easy. Sometimes you are either forced to implement hackish stuff or simply "sacrifice" a feature to keep everyone happy.
Basically, instead of coding diagnostic messages, you could have just disabled the text and the label fields for all launchers when users wanted to disable "The Label" which most likely means "the visual text" to them. I cant imagine when they would want to disable the label but not the text, because they have roughly the same purpose.
What I'm basically doing in Titan when a .text attribute is present is implementing an additional check for .type and .label. If the type equals to launcher and a label is not provided by the DO, then set the label to the .text provided (that is the label in the internal addon table handling the attributes of a plugin and NOT the label on the DO itself). I have also had cases where a DO otherwise marked as a "launcher" would provide both a .label and a .text attribute being equal, at which case I'm simply electing to display only one of them (usually the .label since that can be optionally hidden by the display).
I have said it before and I will say it again. Display authors are in a very difficult position when they make the choice to support every possible deviation out there, especially when that spec is simply an extension of the data source/launcher specs. You need sanity checks everywhere, you need to be very careful when "ignoring" attributes and last but not least you need to be very careful with the options you provide to users, when it comes to hiding stuff. Personally, I have associated .text with something meaningful, some kind of information that is actually helpful in one way or another, which is why I would never use it in a launcher instead of .label. But that's only me or one "school of thought", as Elsia puts it :p
I do agree that warnings and debugging messages can be generally annoying for users and should be defaulted to off, which I believe is the case with DS (and btw this is not directed personally to either Vex or Sylv :p). Still, I think that ultimately Vexxilus shouldn't have catered to the users that just couldn't be arsed to explicitly disable the text field, for the specific plugins that had this "issue". Options are there for a reason.
It's the same endless discussion but to get to the point, the DS author needs to decide whether he wants to support extensions/deviations or not. And I for one, am glad that Tek implemented a working library, even if that meant enforcing his ideas, but still allowing for other implementations. There have been many discussions on wonderful ideas in here that were never concluded or never implemented or the devs just fundamentally disagreed which again resulted in...nothing been done :p
I'm still somewhat unhappy with that because it does give a few wrong impressions. a) The lib is substantially more powerful than doing just that. b) The standard is alpha, open to alternative suggestions and open to extensions and is a separate entity from the lib (lib is just needed to provide the software interface).
I think some clarity that separates lib from standard (or standards) might be good. How's broker-display-standard (BDS)?
You know Elsia, on principle, I agree with this. The problem however is, simply put, users don't care (and you would have a hard time make them understand). They just want their plugins on barX to show and work and for the most part they will be happy. As tek stated, it's just a habbit they are used to for 4 years now and refuse to give up. The library is indeed more powerful and can be easily extended yet in all these months, I've only personally witnessed very little "deviations" that were proven to be viable, in practice. This does not imply that there is a problem with the library, rather than the fact that people spend too much time theorycrafting a new spec or "deviation", that they are missing the entire point and we end up back where we started. Ideas should be encouraged and implemented. If users/authors find them useful, they will follow/adopt them. It's as simple as that.
True, but it can be somewhat frustrating when you need to compensate for attributes that do not belong in a certain data type. You can obviously argue that it's not your problem people don't stick to the spec or decide to bend the "rules" by interpreting things their own way :p
My only gripe with the launcher spec at the moment, is the fact that it doesn't really "allow" tooltips, but neither "forbids" them and simply leaves it up to the display to decide if or how they should be handled. In my own personal opinion, it is very much viable and not really too much of a hassle to have tooltips on launchers/icons, so from that point of view you can actually say that most displays don't obey the spec 100% since they would need to ignore OnEnter/OnLeave/OnTooltipShow attributes for launchers. Which brings us to a much larger issue.
You see, there are also DO's that although specifying the data type as let's say "launcher", they use fields that aren't normally allowed (?) or even intented (?) for that specific object type. The text attribute you refer to and is giving you so much pain, is a prime example of this, you continue to use it, in a launcher DO, although this is not clearly specified anywhere in the spec. So what do we really expect displays and their authors to do ? Become prophets and take (almost) every possible case into consideration ? Well, in many ways, this is what has come down to and it's both a mistake on the part of plugin authors as is on the part of display authors that continue to modify their code in order to support DO Z using some custom spec X, which is more often than not a malformed/modified version of either the data source or launcher, which is not necessarily a bad thing as these plugin authors are of a different opinion on how things should be set/handled. Instead though of declaring their own custom type attribute(s) and then pestering/convincing the display authors to add support for it, they instead use the predefined type attributes, eventually fraking up things and forcing the display author to take action for "that specific case". It's a neverending cycle with no clear "guilty".
From that perspective I could agree that some minimum amount of fields needs to be specified (a generic archetype perhaps that utilizes the very basics of data sources and launchers) for a certain type and from that point on, both plugin and display authors should be free to support/implement whatever other attribute feel it adds that extra feature someone might find useful. However, I do believe that the spec should continue to remain reasonably non-restrictive.
LDB does not "feed" any tooltip, except in one specific case where they handle their own tooltips inside OnEnter (and perhaps when using the tooltip attribute to provide a frame which afaik no one is using atm). Even then, at best they will set some basic attributes (eg Owner if is the GTT or scale etc) and just call the show method. If the tooltip is being redraw on all your ldbfeeds then (maybe) for some reason, your tooltip addon is constantly redrawing the tip (?). Have you enabled profiling to see if tiptac consumes any special amount of CPU when you simply hover over an LDB tip in comparison to regular tooltips ?
I'm aware of the LibDBIcon, afaik both BigWigs and oRA2 (and possibly more) use that kind of implementation to cover the case where a user wants to use these addons but not necessarily have an LDB display installed. In any other case he is free to disable them. I still do not agree with the "acquiring" aspect that implies a lock, who are we to determine what can be considered a "real" display and what can't :p (that's only my opinion though). And I also agree with Elkano.
I'm not sure I understand. You mean, that by using the specified attribute a data object will only be registered and shown by the first display that "acquires" it ? What is the purpose of such a lock ? I'm also not sure if I agree with the term "weak displays". No displays should be limited in any way from registering a DO. If a user wants to use more than 1 display for his UI, then it's his problem, as its each displays responsibility to provide options to hide/show/enable/disable stuff on demand.
Will OnClick actually fire if the user double-clicks and OnDoubleClick fires as a result?
If so, how many times will it fire
As far as I could see from my tests, 1.
and will it be on the first or second click?
First click triggers OnClick and its code. The second will trigger OnDoubleClick and its code, which is why I said that as long as different buttons are being used, its all right. If the same button is being checked again both events, you need some hackish way to only grab the one you are interested in, which may have implications in some cases (delays aren't always accurate afaik).
Is there a way for LDB plugins to determine which handlers an LDB display implements? I'd ideally like to be able to modify F2B to simulate OnDoubleClick only if the display that calls it doesn't provide a real implementation of OnDoubleClick itself.
Not directly, no, since they only provide data and usually not the actual frame/button objects being used. You can probably implement something hackish by exploiting 'self' arguments being used in OnClick and use :GetScript but there are no guarantees that this will work flawlessly with all displays.
Also, is it documented anywhere what the official double click delay threshold is for OnDoubleClick?
I'm not sure that this is set in stone really. Feel free to play around with it though.