• 0

    posted a message on DockingStation (Display)
    Quote from Morgalm
    One 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)
    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on DockingStation (Display)
    Quote from X-buZZ
    Now i have a cosmetically request: Can you please implement the following display settings for texts:

    - shadow
    - outline
    - thick outline
    Done, its in the version I just uploaded on WoWI.
    Posted in: Data Broker AddOns
  • 0

    posted a message on DockingStation (Display)
    Any 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
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    Quote from Azethoth
    1) So I can add editing of the label locally to Broker Currency. I can see how in a non-Fortress display that could be handy. However would it not be better to just support a callback:
    SetLabel(newLabel)

    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.
    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.

    Quote from Azethoth
    2) As for the issue of text on light / dark backgrounds a solution I have seen elsewhere is to provide both a light and a dark version of your text.
    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.

    Quote from Azethoth
    3) Ok, lets assume we only care about the blizzard panel options interface and so a simple clustering solution is to create the "Broker" category if it does not exist.
    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    Quote from Tekkub
    Register 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.
    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.

    Add pairs and ipairs iters, since we can't use the normal iters on our dataobjs
    That comment from when you revised LDB to add the iterators answered my question on intended use of the functions.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    Unfortunately, burying my head in the sand doesn't work for cases like:

    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    When 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?

    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
    Posted in: Data Broker AddOns
  • 0

    posted a message on DockingStation (Display)
    DockingStation is an addon for displaying LDB based plugins. Although it is still in beta, I feel that it is now at a point where it is suitable for everyday use.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    I 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.

    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.

    Say the user wants to have his label edited ("dura:") but consistent between the two displays.
    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LDB display like FuBar?
    I 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.

    DockingStation

    Edit:
    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    I 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.

    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    I 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.

    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    Imagine 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.

    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    I 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'.

    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.
    Posted in: Data Broker AddOns
  • 0

    posted a message on LibDataBroker-1.1 not-really-official thread
    Quote from Torhal
    Please 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.
    Posted in: Data Broker AddOns
  • To post a comment, please or register a new account.