How did you manage to get TomTom Crazy Arrow in the panel
NinjaPanel introduces support for icon colors and coordinates using the following fields in the LDB data object:
iconR - The red component value of the color
iconG - The green component value of the color
iconB - The blue component value of the color
iconCoords - A table containing the texCoords to be set on the icon
I will soon expand iconCoords to support the 8-value version, as well as iconRotate to support arbitrary rotations using the new API.
These features are used in the latest version of TomTom to allow you to display the crazy arrow in NinjaPanel.
Did you tweaked it ? I can not reproduce it with the latest version. The error about nonexistent DO also disappeared.
Actually the original width error was caused by missing DO or the like, so I think you fixed it.
BTW, when I enable the report, I have the following warnings:
WARNING: field 'type' not given, defaulting to 'data source'
DockingStation: creating plugin 'Ammo'
WARNING: field 'type' not given, defaulting to 'data source'
DockingStation: creating plugin 'Durability'
WARNING: field 'type' not given, defaulting to 'data source'
DockingStation: creating plugin 'Money'
WARNING: field 'type' not given, defaulting to 'dat19:42]DockingStation: creating plugin 'Baggins'
WARNING: field 'type' not given, defaulting to 'data source'
DockingStation: creating plugin 'FuBar - FactionsFu'
WARNING: field 'type' not given, defaulting to 'data source'
DockingStation: creating plugin 'FuBar - GuildFu'
WARNING: field 'type' not given, defaulting to 'data source'
DockingStation: creating plugin 'nQuestLog'
WARNING: field 'type' not given, defaulting to 'data source'a source'
Baggins, FuBar - FactionsFu, FuBar - GuildFu and nQuestLog DO are created by FuBar2Broker.
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.
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.
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 :
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.
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
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.
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.
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 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.
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.
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?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
From the NinjaPanel page on WowI.
Actually the original width error was caused by missing DO or the like, so I think you fixed it.
BTW, when I enable the report, I have the following warnings:
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.
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.
That makes no difference. All of my mods that use AceConfig-3.0 plug into the Blizzard Interface menu.
And, looking in the libs folder for DockingStation, it does use AceConfig, so you should just be able to click the number itself.
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 :
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 :
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).
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.
Something like this in dataobj.OnClick:
I can probably go for something like this. Will look into it and test it, in the coming days.
Or is it already in, and I just oversaw it?
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.
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.
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?