Authors CurseForge

I'm working on integrating LDB into my addon (BuffEnough). One of the semantics of BuffEnough is that I may update the tooltip (as buffs are either added or removed) to indicate what's missing, but the general status (buff enough? yes or no) will not necessarily be changed. The API spec for LDB indicates that 'tooltiptext' is meant for a static tooltip, while OnTooltipShow is meant for a tooltip with dynamic content so I assume the latter is for me. However, there's no callback message for "call OnTooltipShow". The best that I can come up with is to have my display module register for the tooltiptext change callback, and then call OnTooltipShow when my buff scanning logic modifies the tooltiptext. But that seems a little hacky to me, since I'm effectively changing the tooltip twice. Is that the intended usage, or is there something really obvious that I'm missing?

use OnEnter/OnLeave with GameTooltip:foo

If your tip needs to be refreshed while it is open you should use OnEnter/OnLeave. Then you're responsible for anchoring, erasing and showing... which you'll have to do when you refresh the tip anyway.

Look at my picoFriends, it provides OnEnter/OnLeave. You would just have to essentially call OnEnter and pass the frame whenever you wanted to refresh the tip while it was open.

OnTooltipShow doesn't work if you wish to refresh the tooltip while it is open. To do that, the plugin needs to just take over control of the tooltip, cause the display doesn't know when the tip needs refreshed.

Thanks for the responses. I'm not too keen on controlling the tooltip from the non-display portion of the addon, but it seems like I may not have a choice. Is it considered beyond the scope of the display component to know when tooltip data has changed? It doesn't seem like a too far-fetched scenario for a data feed to want to provide dynamic data but not take on ownership of the display frame. One simple way around this would be to add a "dirty" field for the tooltip, for which displays could register a callback and know that dynamic tooltip content has updated and needs refreshing. (This is effectively what I'm doing with tooltiptext).

Frankly, tooltips suck ass. The whole "owner" thing makes no sense, and when you clear a tooltip's lines the owner is cleared and the tip is hidden... it's all really quite weird to me that the tooltip can't simply anchor and parent like all the other frames and be happy with that. How the hell is "owner" any different than "parent"?

Another thing you could do is provide a tooltip frame via .tooltip, and refresh it OnShow and when it is visible and needs redrawn. Should even theoretically work with a GameTooltip-type frame (but not *the* GameTooltip, you have to make your own frame noone else will touch). That is the point of the .tooltip field, to let the display retain control of how the frame is shown, and the plugin retain control of when to refresh.

Just have to make sure that the owner bullshit doesn't break the tip, if the plugin uses .tooltip the display cannot expect a GameTooltip type frame, so it can only anchor/show/hide, not SetOwner.

But you use OnEnter, which he doesn't want to.

.tooltip is the solution you want if you don't want yours plugin handling the tooltip's positioning/showing/hiding. Noone uses that currently, but I'm sure someone will soon.

Quote from tekkub »

Frankly, tooltips suck ass.

True story. Thanks for the tips (no pun intended).

After some consideration, we're changing the launcher spec slightly. Instead of using launcher = true we're going to use type = "launcher".

Using a generic "type" attr will lets other user-created specs use the same field to declare their spec type, so display addons can ignore other dataobjects without having to check a bunch of potentially unknown flags. type = nil will "default" to Fu-ish data display addons.

The API docs have been updated accordingly.

I wouldn't mind a type string for data objects, so I can make sure the stuff I try to display follows the correct specs.

"data source" work? Funk doesn't want to have to go back and add that to all his plugins though, so you should probably also consider nil, or give the user the option to render "undefined" types.

yeah, it's fine. Like web browsers you can just render something in compatibility mode, if no doctype is given. I just think it is a good idea, esp. because LDB is so generic, it can be used for everything. Someone could out of the blue use it for something completely different, so type helps here.

I couldn't find a thread on dbSocial - my apologies if this posting upsets people...

I notice with dbSocial from the SVN that the GUILD list only shows up if I reload my ui. Initially upon entering the world only the friends block shows up on the screen and in "Fortress". When I reloadui the guild block shows up both on the screen and in Fortress.

Quote from Flarin »

I couldn't find a thread on dbSocial

If you can't find one, and you honestly searched, then start one.

Quote from Elkano »

besides tooltips sucking as you say, I don't think the data addon should handle positioning of the tooltip even if it wants to have control about showing/hiding it, at least as long as there is no common way to position the tooltip sicnce this can easily lead to inconsistent positioning in the same display addon.

Maybe the display could pass a callback to the OnEnter function that can be used to have it position the tooltip.
(I really should test how easy the evil TabletLib can be used together with LDB for clickable tooltips...)

TabletLib works with no problems with LDB, check FuBar2Broker.