Authors CurseForge

Quote from Adirelle

Baggins, FuBar - FactionsFu, FuBar - GuildFu and nQuestLog DO are created by FuBar2Broker.

FuBar2Broker only sets the type field to "launcher" if it thinks what it's "translating" is a launcher... otherwise it doesn't set it. I've modified my local copy to default to "data source" for non-launchers, but someone should probably change this in the actual version too.

It looks like all Fuber2Broker renderings do not properly remember text/icon sizes.

I can reset them to what I want, but a reloaded UI always resets them back to the (largish) default

Also, is there a way to increase the hover delay? I'd like to have it not pop open with just a mouseover, I'd like it to have a 1/2 sec (or longer) delay on opening.

Am I missing something? I have a bar below my action bars. I'm trying to change it's width to be exactly the same as my action bars, however the slider's granularity leaves much to be desired. Is there some place to type in then number?

It's part of the Blizzard addons tab, so I don't think it uses the Ace3 slider widget. Barring making the slider a whole lot more sensitive, a slash command would be great. Anything where I can adjust and align size and position to the pixel.

Awesome addon. It's FuBar, but so much sleaker and pretty.

Quote from Adirelle

Broker_ItemRack seems to have issue to display ItemRack menu with DockingStation but works fine with, by example, Fortress. I suspect something is going wrong with the OnClick handler but I could not say what.

I can, because it's most likely the exact same issue that existed with ButtonBin before I had a discussion with dhedbor :p

Broker_ItemRack uses the following function to anchor and display the menu, that exists inside the Itemrack addon :

function ItemRack.DockWindows(menuDock,relativeTo,mainDock,menuOrient,movable)
    ItemRackMenuFrame:ClearAllPoints()
    ItemRack.currentDock = mainDock..menuDock
    ItemRackMenuFrame:SetPoint(menuDock,relativeTo,mainDock,ItemRack.DockInfo[ItemRack.currentDock].xoff,ItemRack.DockInfo[ItemRack.currentDock].yoff)
    ItemRackMenuFrame:SetParent(relativeTo)
    ItemRackMenuFrame:SetFrameStrata("HIGH")
    ItemRack.mainDock = mainDock
    ItemRack.menuDock = menuDock
    ItemRack.menuOrient = menuOrient
    ItemRack.menuMovable = movable
    ItemRack.menuDockedTo = relativeTo:GetName()
    ItemRack.MenuMouseoverFrames[relativeTo:GetName()] = 1 -- add frame to mouseover candidates
    ItemRack.ReflectLock(not ItemRack.menuMovable)
    ItemRack.ReflectMenuScale()
end

It's simply calling the function using the 'self' argument for 'relativeTo' from .OnClick(self, button) and using values for 'menuDock' and 'mainDock' derived from the following local function :

local function GetTipAnchor(frame)
    local x,y = frame:GetCenter()
    if not x or not y then return "TOPLEFT", "BOTTOMLEFT" end
    local hhalf = (x > UIParent:GetWidth()*2/3) and "RIGHT" or (x < UIParent:GetWidth()/3) and "LEFT" or ""
    local vhalf = (y > UIParent:GetHeight()/2) and "TOP" or "BOTTOM"
    return vhalf..hhalf, frame, (vhalf == "TOP" and "BOTTOM" or "TOP")..hhalf
end

Now, my guess is that the 'self' frame argument being passed to the OnClick attribute is nil so ItemRack.DockWindows isn't getting a valid frame to anchor the menu to. I had a workaround in place some time ago to use the parent frame but I removed it, as soon as ButtonBin started naming its DO frames.

I obviously cannot alter the docking function inside Itemrack, unless I write my own which is something I want to avoid, since I don't want to complicate it by having to "detect" the display addon and act accordingly. If you have any other viable solution that can be implemented from my end, I'm all ears (and eyes).

The problem is that some of ItemRack's functions were designed around using frame names and getglobal(frameName) instead of just generic frame references. Since Broker_ItemRack is using one of those functions it is checking that all frame references passed also have a name. When DockingStation passes a frame reference its not nil but fails the second part of the check (if self and self:GetName() then ...).

DockingStation does not name its frames because my opinion is that addons should have a minimal impact on the global namespace. It is just as easy to keep and pass frame references as needed and is generally more efficient. There are cases where frame names are actually important but this isn't one of them.

Having never used or looked at ItemRack previous to this, it took me less than 20 minutes to download it and Broker_ItemRack and make the necessary code changes to use frame references over frame names with ItemRack.DockWindows and all interacting code.

ItemRack.lua = 11 lines changed and 1 line removed
ItemRackButtons.lua = 1 line changed
Broker_ItemRack.lua = 2 lines changed

I can provide the changed code snippets if desired.

Forget what I said, go with Adirelle's suggestion. Now I just need to find a short bus to take to work tomorrow for not thinking of that.

Quote from Adirelle

Actually a solution not involving changing ItemRack would be preferable. I think it should lie in Broker_ItemRack. What about creating a named frame in Broker_ItemRack that you (re)anchor to the self argument of OnClick and then pass to ItemRack.DockWindows ?

Something like this in dataobj.OnClick:

  local anchorFrame = _G["Broker_ItemRack_Anchor"]
  if not anchorFrame then
    anchorFrame = CreateFrame("Frame", "Broker_ItemRack_Anchor")
  end
    
  anchorFrame:ClearAllPoints()
  anchorFrame:SetAllPoints(self)
     
  
  -- then use anchorFrame as an anchor for ItemRack

I can probably go for something like this. Will look into it and test it, in the coming days.

Would it be possible to add the creation of vertical panels as well?

Or is it already in, and I just oversaw it?

Quote from Tristanian

I can probably go for something like this. Will look into it and test it, in the coming days.

Version 1.7 of Broker_ItemRack should fix the issue with the menu not appearing on left-click, on displays that utilize generic frame references (thanks Adirelle). Please say so, if that is not the case.

Quote from Adirelle

Vexxilus, could it be possible to have an option to disable mouse interaction with the panels (but not the plugins) ? It could be either integrated in the lock option or an individual option.

I actually have something like this in the version I'm working on atm. Basically the lock mechanism is a drop-down menu to select what is unlocked with choices of panels, plugins, or both.

Quote from Adirelle

Edit: this would be useful when putting something in the holes between left, center and right part. ATM the panels mask anything. In second thought, moving the panels in a lower frame strata when they are locked may achieve the same effect.

I don't think I understand this part. Currently when dragging a plugin it's strata layer is changed to the highest possible then restored to its original when the dragging stops. Could you maybe explain what's occurring in a different way?