Does that mean no durability or tracking SBC modules are planned? Not a problem if so, just would like to know.
Broker_ addons ARE SBC modules. There is just no good naming convention yet. There is (afaik) no difference between a statblock_module and broker_module (note statblock, not statblocks).
Suggestion for StatBlock_Rangedstats: Block to see your current Hunter's Mark strength. I know there's allready an addon like this on the SVN, but i heard it's quite buggy. Nothing too important, but would be nice nevertheless. Also, if you could fix Broker_Durability as it currently shows overall durability as default and not the lowest durability value. My bow broke midfight when Durability showed 37% dura overall.
Seems to be a disparity between SBC and Fortress on the LDB tooltip implementation. Specifically, SBC appears to use both .OnTooltipShow and .tooltiptext simultaneously, if they're both there, whereas Fortress uses one and only one (.tooltiptext first, I believe, and then .OnTooltipShow if the former isn't present). Posting here because I think Fortress is doing it correctly according to my understanding of the LDB spec.
Actually fortress is doing it wrong... only one tooltip method should be employed at any given time. It's basically up to the display to pick priorities, but the logical order, at least in my brain, would be OnEnter/OnLeave > tooltip > OnTooltipShow > tooltiptext.
I meant specifically with regards to using more than one tooltip method simultaneously (ie. the tooltip has the same text appear twice), rather than picking one and only one. In terms of priority, your ordering makes sense, most to least dynamic. But the data feed shouldn't make any assumptions about which one the display will choose in which order, so it probably doesn't matter anyway.
Suggestion for StatBlock_Rangedstats: Block to see your current Hunter's Mark strength. I know there's allready an addon like this on the SVN, but i heard it's quite buggy. Nothing too important, but would be nice nevertheless. Also, if you could fix Broker_Durability as it currently shows overall durability as default and not the lowest durability value. My bow broke midfight when Durability showed 37% dura overall.
I have no idea what hunters mark strength is or how it works to know if it's appropriate to be in there, as for durability, I'll take a look later.
Quote from Nikkodemus »
Seems to be a disparity between SBC and Fortress on the LDB tooltip implementation. Specifically, SBC appears to use both .OnTooltipShow and .tooltiptext simultaneously, if they're both there, whereas Fortress uses one and only one (.tooltiptext first, I believe, and then .OnTooltipShow if the former isn't present). Posting here because I think Fortress is doing it correctly according to my understanding of the LDB spec.
I assume the plugin has one or the other, not both, I don't see why on earth it should have both. It should only have OnEnter if it wants to do stuff itself with the tooltip, otherwise OnToolTipShow, and save a few lines of code.
I assume the plugin has one or the other, not both, I don't see why on earth it should have both. It should only have OnEnter if it wants to do stuff itself with the tooltip, otherwise OnToolTipShow, and save a few lines of code.
Actually, SBC does assume the plugin has both because it's only adding .tooltiptext if the plugin is also providing .OnTooltipShow:
if evt:find("OnTooltipShow") then
...
if obj.tooltiptext then _G.GameTooltip:SetText(obj.tooltiptext, 0.5, 0.5, 0.8) end
...
else
As to why there might be both, I understood from the dataobject example in the LDB documentation, that a display addon doesn't necessarily have to implement all of the various tooltip functions, and so the data feed may implement different options depending on how fancy the display wants to get. The example code shows .tooltiptext, .OnTooltipShow, and .OnEnter/OnLeave all implemented. I may be taking that example too literally though. Is the intent for the data feed to provide one and only one means for the tooltip?
I meant specifically with regards to using more than one tooltip method simultaneously (ie. the tooltip has the same text appear twice), rather than picking one and only one. In terms of priority, your ordering makes sense, most to least dynamic. But the data feed shouldn't make any assumptions about which one the display will choose in which order, so it probably doesn't matter anyway.
Oh, I read your comment backwards... I thought you were saying it *should* do more than one at once. Yea, the display should only use one method. The data provider may provide more than one... generally speaking tooltip and tooltiptext will probably not provide another method, because they're both after a specific feature. OnEnter/OnLeave and OnTooltipShow are easy to mix together, so it's highly likely that if a feed provides OnEnter it'll also provide OnTooltipShow unless it's doing weird fancy shit like clickable tooltips.
Actually, SBC does assume the plugin has both because it's only adding .tooltiptext if the plugin is also providing .OnTooltipShow:
if evt:find("OnTooltipShow") then
...
if obj.tooltiptext then _G.GameTooltip:SetText(obj.tooltiptext, 0.5, 0.5, 0.8) end
...
else
As to why there might be both, I understood from the dataobject example in the LDB documentation, that a display addon doesn't necessarily have to implement all of the various tooltip functions, and so the data feed may implement different options depending on how fancy the display wants to get. The example code shows .tooltiptext, .OnTooltipShow, and .OnEnter/OnLeave all implemented. I may be taking that example too literally though. Is the intent for the data feed to provide one and only one means for the tooltip?
I'm talking about both as in OnEnter and OnTooltipShow not OnTooltipShow and .tooltiptext, they both go together if you want. I'm not sure why you assume I was talking about that when my code is totally contradictory of that. :P
I didn't make any mention of OnEnter/OnLeave in my original bug report, so it didn't occur to me that you might be talking about those methods. When I said:
SBC appears to use both .OnTooltipShow and .tooltiptext simultaneously, if they're both there
you replied
I assume the plugin has one or the other, not both, I don't see why on earth it should have both
So I'm not sure which one of us is confused (probably me), but the bottom line is that if a data feed implements both .tooltiptext and .OnTooltipShow, I don't think SBC should show the text twice in the tooltip.
Ideally speaking, if OnEnter is provided, the display should set it to the frame directly, so the display's tooltip code that calls OnTooltipShow should never even execute...
A string for the display addon to pass directly to GameTooltip:SetText() when a tooltip is needed.
As I read this it's an addition to what you want at the top of the tooltip, like a title or addon name.
Quote from tekkub »
Ideally speaking, if OnEnter is provided, the display should set it to the frame directly, so the display's tooltip code that calls OnTooltipShow should never even execute...
Not sure what you're getting at with this, I handle the positioning of the tooltip already.
Broker_ addons ARE SBC modules. There is just no good naming convention yet. There is (afaik) no difference between a statblock_module and broker_module (note statblock, not statblocks).
hmm I think yes. also the ability to hide unneded @buttons@ from that menu :-/
But I think its possible to just make this menu such a tiny via some bar addons...need to test
edit: think I was using Fortress, maybe that's why; will double check later.
You misunderstand, download the broker_* addons, install them, /sbc and tada :)
Has both click and tooltip, both work in SBC at least.
I have no idea what hunters mark strength is or how it works to know if it's appropriate to be in there, as for durability, I'll take a look later.
I assume the plugin has one or the other, not both, I don't see why on earth it should have both. It should only have OnEnter if it wants to do stuff itself with the tooltip, otherwise OnToolTipShow, and save a few lines of code.
Actually, SBC does assume the plugin has both because it's only adding .tooltiptext if the plugin is also providing .OnTooltipShow:
As to why there might be both, I understood from the dataobject example in the LDB documentation, that a display addon doesn't necessarily have to implement all of the various tooltip functions, and so the data feed may implement different options depending on how fancy the display wants to get. The example code shows .tooltiptext, .OnTooltipShow, and .OnEnter/OnLeave all implemented. I may be taking that example too literally though. Is the intent for the data feed to provide one and only one means for the tooltip?
Oh, I read your comment backwards... I thought you were saying it *should* do more than one at once. Yea, the display should only use one method. The data provider may provide more than one... generally speaking tooltip and tooltiptext will probably not provide another method, because they're both after a specific feature. OnEnter/OnLeave and OnTooltipShow are easy to mix together, so it's highly likely that if a feed provides OnEnter it'll also provide OnTooltipShow unless it's doing weird fancy shit like clickable tooltips.
I'm talking about both as in OnEnter and OnTooltipShow not OnTooltipShow and .tooltiptext, they both go together if you want. I'm not sure why you assume I was talking about that when my code is totally contradictory of that. :P
you replied
So I'm not sure which one of us is confused (probably me), but the bottom line is that if a data feed implements both .tooltiptext and .OnTooltipShow, I don't think SBC should show the text twice in the tooltip.
As I read this it's an addition to what you want at the top of the tooltip, like a title or addon name.
Not sure what you're getting at with this, I handle the positioning of the tooltip already.