This is a bug with the plugin. The OnEnter handler works like a method defined as frame:OnEnter(motion) but the guild plugin sets its up as frame:OnEnter(dontShow). When I pass the motion parameter it is getting placed into the variable dontShow, and as the name suggests its doing just that. Its a very easy fix if you let the author know about the problem.Quote from MorgalmOne oddity I noticed is with Ara guild/friends. The friends tab works fine on hover but the guild tab won't show unless I right click the LDB icon (right click changes display style)
- Registered User
Member for 11 years
Last active Fri, Oct, 4 2013 14:33:02
- 0 Followers
- 63 Total Posts
- 0 Thanks
Dec 18, 2008Posted in: Data Broker AddOns
Dec 17, 2008Any chance someone getting the width error could list the addons they are using that generate LDB plugins? I'm already using Broker_Factions and StatBlock_Money and they aren't generating that error. StatBlock_Money did create an error via a bug in LibDataBroker-1.1 which I've corrected in my code until it, LDB, is fixed.Posted in: Data Broker AddOns
Dec 17, 2008Posted in: Data Broker AddOns
Considering the number of plugins that still don't provide a type field it would have to be up to displays to store/restore a user edited label. Of course there is still the issue of multiple displays allowing label edits and a user changing the label in one then changing it again but on the other. How does the first display know to allow the new label to go through and not reset it to what it has stored without a system in place for them to resolve such an issue? Also, I'm not sure what you mean by supporting callbacks since any change of a field generates 4 callbacks.
and then store the custom label? This moves label editing to displays that care about that, and then peer pressure can get the callback implemented where needed? The drawback to that would be simple mods a la Tekkub that do not even store anything. Those could eschew storing it and require it to be set again next time and place the storage onus on the display that wants it modified and can thus control when to set it etc.
Then you could still have situations of red text on a red background or the like. This again should really be up to the display to resolve either by providing a way to change text/background coloring or more generically through a function that generates a useful complement color if it only allows changing of one or the other.
This is a good idea for a library as I think you mentioned later. A suggestion though. If you or someone else makes this, add a way to hide entries since a few plugins I've downloaded for testing purposes did nothing but fill the Addons tab with glorified "About" screens.
Dec 17, 2008Posted in: Data Broker AddOns
Honestly, I was just trying to report a suspected bug in your code. I can code around it just fine on my own. I'm more worried about people down the line writing new displays or other implementations (since it is meant for broader use than just plugins) wasting their time tracking down the same issue.Quote from TekkubRegister for the callback on the DO's type field, do what you need to do when it's set, if it's set to the type you support.
That comment from when you revised LDB to add the iterators answered my question on intended use of the functions.Add pairs and ipairs iters, since we can't use the normal iters on our dataobjs
Dec 16, 2008Unfortunately, burying my head in the sand doesn't work for cases like:Posted in: Data Broker AddOns
local DO = LibStub('LibDataBroker-1.1'):NewDataObject("cleverName")
DO.type = 'launcher'
DO.icon = "icon.blp"
DO.OnClick = function() end
Which, sadly, is how several plugins set themselves up.
Dec 16, 2008When creating a new DO without passing a table such as ldb:NewDataObject("pluginName"), any addon monitoring "LibDataBroker_DataObjectCreated" will cause an error if it uses ldb: pairs() on that new DO. This is because ldb.attributestorage[DO] is not defined in that case until __newindex is invoked. Is this intended behavior or a bug?Posted in: Data Broker AddOns
I only ask because I'm using ldb: pairs() to check all fields available on DO creation but can't because of this issue. I could get around it by setting some off-the-wall field to a value then nil again right after, but that seems rather hackish.
Edit: Stupid smilies
Dec 4, 2008I actually planned on adding a way to change the labels in my display. Only locally of course, since I thought changing the DO was a no-no for displays. Because the label isn't really critical information and is really there more for ease of the end user I did consider allowing a global change until I thought of a scenario where it could get ugly.Posted in: Data Broker AddOns
Since a label isn't required it can be set by an addon after creation of the DO. A display that lets you change labels will need to save that change to apply on reloads. I would assume that any time the display sees the label get changed by an AttributeChanged event it will turn around and change it back. Now what happens if you have two displays that let you change labels? How will one know when to let the change go through and not end up in a constant loop of the two changing the label back and forth?
If the label change is for the display only then it can just ignore changes but since its trying to apply the change to all displays there really isn't a good alternative. Maybe a field in the DO to indicate any changes that happen while it's set are by user request and should always be applied? That would fix the issues for labels and if displays ever start letting you change icons for launchers it would help with the same scenario with that (that has a few issues in addition to this).
So the real issue is should displays really be changing a DO in the first place? I think that label changing should be allowed but then that means something has to be put in place to allow for it without risk of looping.
No matter what is decided there probably should be an option to only change labels for that one display or a disclaimer stating that it will effect all labels.
Is the label supposed to have the ":" in it? All the addons I've been testing my display with don't so I was basically using >> label .. ": " .. text << in my code. If some addons are already applying their own stuff to the end of their labels I'll need to revist how I handle that.Say the user wants to have his label edited ("dura:") but consistent between the two displays.
Dec 3, 2008I gave it a shot and this is what I came up with. Its not fully functional yet but you can create panels and throw plugins into them. You can move them around fairly easily as well.Posted in: Data Broker AddOns
I'll mention that you can choose to have plugins on the left, right, or centered in the middle. Aso, you can drag and drop between these sections and even between other panels.
Dec 3, 2008I don't think making .label required is a good idea, if anything just change the description of it to state if not provided that the name will be used (instead of may). That gives you the ability to finger point at display mods if they don't follow it rather than make it forced on both sides.Posted in: Data Broker AddOns
Having said that, I don't think either of the current two types should be changed at all. The community as a whole just needs to take time and come up with a new type (or types) that fit what is needed and that learn from what we know now.
A templated system utilizing an .inherit field for future types could work. Have a tooltip template with all those fields, an icon template with its fields (add .texcoord), maybe a color template, and so on. Then you could make a 'launcher v2' type that inherits the tooltip and icon templates.
And if some new types are decided on, I'd like to see a better solution to the text/value+suffix situation.
Nov 29, 2008I think I know how to handle the backwards compatibility of different types now using the system as is. I was just thinking about it the wrong way.Posted in: Data Broker AddOns
Now I still have the question of whether or not the 'texcoord' field is supposed to be part of the 'data source' and 'launcher' types? I'm supporting it in my display because I think it should be standard even if its not. However, I want to ensure any plugins I make look right when used by other displays so it is still an issue for me from that side of things.
Nov 28, 2008Imagine one day down the line everyone agrees that 'data source' needs reclarification (got off to a rough start). Instead of changing that spec and breaking displays, the community makes a new data type 'data source v2.' With .ignore in place plug-ins could provide dual support for both specs without worry. Additionally, any non-standard specs could also use the field to indicate for displays to not even bother trying to force the DO into a 'data source' format.Posted in: Data Broker AddOns
Clarification of the ignore field:
Field Type Description ----- ----- ----------- ignore any This is for non-standard types. If the value provided evaluates as true then displays should not try to create the DO if they don't support the type. If the value's type is a string (or a table containing a list of strings) then displays should not create any future DO's with a matching name.
Pseudo-code to show how a display could evaluate creating a DO or not:
function myAddon:CanCreateDO(name, dataobj, force) if IsOnIgnoreList(name) or AlreadyExists(name) then return end local type = force or dataobj.type or (dataobj.launcher and 'launcher') or 'data source' local ignore = dataobj.ignore if not IsSupportedType(dataObj.type) then if ignore then return else return self:CanCreateDO(name, dataobj, 'data source') end end if not IsDataOk(dataobj) then if not (IsStandardType(dataobj.type) or ignore) then return self:CanCreateDO(name, dataobj, 'data source') end return end if ignore then if type(ignore) == 'string' then AddToIgnoreList(ignore) elseif type(ignore) == 'table' then for _, name in pairs(ignore) do if type(name) == 'string' then AddToIgnoreList(name) end end end end return true end
This is assuming 'name' is always a string of course.
Nov 27, 2008I think there is a minor issue with LibDataBroker-1.1. When creating a new DO with NewDataObject(name, dataobj), 'dataobj' is type checked to ensure it's a table but no verification is done with 'name'.Posted in: Data Broker AddOns
From a purely coding standpoint this could lead to errors when concatenating 'name' with the event when firing a callback.
As for display authors, I'm sure they'd like for 'name' to always be a string or number to ensure each object will always have the same name for saving settings on a per add-on bases.
I know this would be noticed and corrected in the debugging phase, like I said, just a minor issue.
Edit: Same issue with the keys in 'dataobj' but that is more easily corrected with tostring() before concatenating.
Nov 27, 2008Posted in: Data Broker AddOnsQuote from TorhalPlease elaborate.
FuBar-BagBar: Issues with receiving dragged items, graying out the buttons when unuseable (Game Menu open), and need to be able to SetTexCoord for some textures.
FuBar-Compass: Need to layer textures. A texture for the compass pointer on top of the main compass texture (which needs SetTexCoord to work).
FuBar-LuckyCharms: Need to know the position of each icon in relation to the others for the kill order.
FuBar-MicroMenu: The 'Main Menu' button colors the screen of the icon's computer requiring an overlay on the icon, need to use SetTexCoord for the icons.
The compass could probably be done generically in text some how, or use a bunch of predone textures for various compass positions (waste of disk space and effort imo). The micro menu button in question could be handled with additional icons precolored but I modified it to be a smooth transition vice discrete points like in the Blizzard default so that's a loss in my mind. I could rework the kill order bit on LuckyCharms but I really like the way it currently is and don't want to go to a subpar option panel fix.
If the 'texcoord' field is standard but just not documented (or I missed it) then that cuts down some of my issues.
- To post a comment, please login or register a new account.