You currently can't set the width of the object in your __call = func function if you have the 'initial-width' and 'initial-height' values set in your :RegisterStyle table. oUF calls func first, then attempts to set the frame's width and height to the initial-* values if not in combat.
In a nutshell, if you want frames with different sizes, you need to register new styles with appropriate initial-* values. There's an alternative, but I don't know if haste purposefully tried to override any self:SetWidth and self:SetHeight calls in func.
<Frame>
...
<Layers>
Textures and font strings, etc.
</Layers>
<Frames>
Child frames.
</Frames>
</Frame>
So while I can't say I'm certain, I think that the layer only applies to the drawn elements (textures and the like) of the given frame, and then the child frames are drawn on top of all of that.
First thing I would try, Moon, would be something like this:
local PostCreateAuraIcon = function(self, button)
button.count:SetParent(button.cd)
--...
end
You may need a button.count:SetDrawLayer"OVERLAY" also.
If you attach your layout, I'll take a look at it.
Just a guess, since this was the biggest thing to change recently, but are you still using the ["raid-attribute"] things in your metatable? If so, you'd need to update it so that only the following entries are in the :RegisterStyle metatable (with your values, of course):
Ah, I misunderstood. (Is it obvious that I don't use this mod?) The click-cast idea should still work, in theory, but you would have to use your button differently (specifically, click once to start/stop; click again to stop/start). I know you can watch for anydown in general with RegisterForClicks, but I don't know if it's possible with Clique.
Note: this is really ghetto looking and I've been meaning to redo it. Also, I'm not sure why the grouping order is necessary here, but it avoids an error with the Blizzard code.
This will only work with the latest oUF, by the way.
Ok, what I am about to say is based on the assumption that you want to start this mouselook thing whenever you are over unit frame, and you want to use a mouse button to do it.
Have you tried getting Clique and setting up a custom macro (to start/stop mouselook) for mouse4? I don't know if this will work the way you want because I think Clique watches for the release of the mouse button rather than the initial press, but it's an idea to consider. :)
Hrmmm. So am I the only one having trouble getting the semicolon key to bind to anything? I know it's probably a little weird, but does anyone else have semicolon bound and working in Bongos3?
I don't remember how I managed to fix this, but you should be able to do it by messing with the saved variables (WTF/Account/ACCOUNT/SavedVariables/Bongos.lua). Then just find the bindings section for the bar you want. One of mine is this:
I had a pain in the ass trying to bind SHIFT-;, but it's working for me. If changing the saved variables doesn't work for you (I didn't have to do it, I'm just guessing this will work), try unbinding it, rebinding it, unbinding it again, binding it directly to a spell in your spellbook, and binding it to the button you want. It was some random permutation of those actions that did it for me; maybe you'll have some luck.
Hi. Back with one suggestion for the aura element: spacing.
local spacing
function oUF:SetAuraPosition(icons, x)
if(icons and x > 0) then
col = 0
row = 0
size = icons.size or 16
spacing = icons.spacing or 1
anchor = icons.initialAnchor or "BOTTOMLEFT"
growthx = (icons["growth-x"] == "LEFT" and -1) or 1
growthy = (icons["growth-y"] == "DOWN" and -1) or 1
cols = math.floor( (icons:GetWidth() + spacing) / (size + spacing) )
rows = math.floor( (icons:GetHeight() + spacing) / (size + spacing) )
for i = 1, x do
if(row > rows) then break end
button = icons[i]
button:ClearAllPoints()
button:SetPoint(anchor, icons, anchor, col * (size + spacing) * growthx, row * (size + spacing) * growthy)
if(col >= cols) then
col = 0
row = row + 1
else
col = col + 1
end
end
end
end
Don't mind doing it myself, just thought it would be nice to have that option in the core.
You can already set unique attributes per header you spawn. I don't really see a reason to add the extra tables and such, since it's already possible:
local raid2 = oUF:Spawn("raid", 2)
raid2:SetAttribute("showRaid", false)
-- and so on.
:Spawn returns the headers, so you are pretty much free to do what you want.
God I never even noticed that. All right, thanks for the tip. Just go ahead and ignore my babbling, then :)
Quote from Moon Witch »
While this imho is all good, the way it's currently set up, you can opt in a layout to show or text based or image based. A simple
if UnitIsFreeForAll(self.unit) then
set the right texture
elseif UnitIsPVP(self.unit) then
set the faction texture
end
in a layout should do it.
I wasn't suggesting he change it to mine, I was illustrating why I'd like something like he did with the power element (( if(self.PostUpdatePower) then self:PostUpdatePower(event, bar, unit, min, max) end )) for the pvp element as well so the texture/text can be updated to ffa/pvp when the UNIT_FACTION event occurs. If you are saying that there is a way to do this from the layout (other than registering the UNIT_FACTION event myself), would you mind showing me how?
Thanks for the response! What I meant with the last idea was to add the ability to have multiple raid headers with unique attributes (the most useful of which being the groupFilter attribute), so you could set up different headers for each raid group, or each class, or whatever. For example:
The needsHeader thing was just a flag to say whether or not this spawn would need a secure header set up for it, but is unnecessary as what you do by checking for the unit being "party" or "raid" is enough. (Like I said, I never really tried to implement this!) I was also thinking that maybe one would want to set up unique attributes for the other frames (party/focus/target/etc), but I didn't give any thought to how useful such a feature would actually be.
As for missing attributes, no, I'm not missing any I would use (if there are even others to use). I suggested a table just because it seemed easiest from a maintenance point of view: the user would specify whatever they wanted, and you'd just have to do a pairs() over the table and not worry about it.
I have a few suggestions. They aren't crucial or anything (I'll probably continue to use my 80% copy/paste, 20% hack version of ouf), but you might like them.
1. pvp element
function oUF:UNIT_FACTION(event, unit)
if(self.unit ~= unit) then return end
if(UnitIsPVPFreeForAll(unit)) then
self.PvP:SetTexture("Interface\\TargetingFrame\\UI-PVP-FFA")
self.PvP:Show()
else
local factionGroup = UnitFactionGroup(unit)
if(factionGroup and UnitIsPVP(unit)) then
self.PvP:SetTexture("Interface\\TargetingFrame\\UI-PVP-"..factionGroup)
self.PvP:Show()
else
self.PvP:Hide()
end
end
end
This is what I made before you did your own module. Maybe you can add a "PostUnitFaction" or "PostPVPUpdate" call to your :UNIT_FACTION() like you did with some of the other elements, too, so people can update the texture/text from the layout?
2. Level text.
function oUF:UNIT_LEVEL(event, unit)
if(self.unit ~= unit) then return end
self.Level:SetText( (UnitLevel(unit) or "wtf") .. " " .. (UnitClass(unit) or "wtf"))
end
function oUF:PLAYER_LEVEL_UP(event, newlevel)
if(self.unit ~= "player") then return end
self.Level:SetText( (newlevel or "wtf") .. " " .. UnitClass"player")
end
Another idea. I made it specifically for my layout (hence the unit class) and didn't really test it (hence the "wtf" is still there). For me, seeing the level of my target on my unit frame is pretty crucial.
3. Generic raid headers. I never really got around to doing this myself, but what I was thinking was changing the table that you send to :RegisterStyle to be something more like this:
And then you'd have to change the oUF spawn and initobject methods to accommodate. Like I said, I never really got around to trying this, so it might not work as presented. The idea, though, was that you could specify arbitrary headers/attributes in the layout and make a raid header for, say, just tanks, or the whole group, or whatever the secure templates allow. And then you'd just call :Spawn(unit, name, key) (with a default value for key being 'default'), and the name field would be the name of the header (or frame if no header was present) in the form "oUF_"..name, which you could check in your layout function to determine how to set up the layout of the frame.
These are just some ideas to consider. If you don't want to do them because they are dumb/a pain in the ass, it's all good :) Thanks for the great mod.
0
In a nutshell, if you want frames with different sizes, you need to register new styles with appropriate initial-* values. There's an alternative, but I don't know if haste purposefully tried to override any self:SetWidth and self:SetHeight calls in func.
0
So while I can't say I'm certain, I think that the layer only applies to the drawn elements (textures and the like) of the given frame, and then the child frames are drawn on top of all of that.
First thing I would try, Moon, would be something like this:
You may need a button.count:SetDrawLayer"OVERLAY" also.
0
0
0
Just a guess, since this was the biggest thing to change recently, but are you still using the ["raid-attribute"] things in your metatable? If so, you'd need to update it so that only the following entries are in the :RegisterStyle metatable (with your values, of course):
And then set the attributes you want directly to the header:
You can also set the attributes one at a time:
Sorry if this is way off; if you post your layout I may be able to provide better feedback.
0
Oh well; good luck with your problem.
0
Party targets:
Just make four of those, replacing the 1 as needed (party2target and so on). You don't need to do anything special.
Party pets are done with a header; you can set that up the same way you do for the party header.
Note: this is really ghetto looking and I've been meaning to redo it. Also, I'm not sure why the grouping order is necessary here, but it avoids an error with the Blizzard code.
This will only work with the latest oUF, by the way.
0
Or just solve the general problem: if you register two styles, initObject always calls the last registered one.
0
Have you tried getting Clique and setting up a custom macro (to start/stop mouselook) for mouse4? I don't know if this will work the way you want because I think Clique watches for the release of the mouse button rather than the initial press, but it's an idea to consider. :)
0
I don't remember how I managed to fix this, but you should be able to do it by messing with the saved variables (WTF/Account/ACCOUNT/SavedVariables/Bongos.lua). Then just find the bindings section for the bar you want. One of mine is this:
I had a pain in the ass trying to bind SHIFT-;, but it's working for me. If changing the saved variables doesn't work for you (I didn't have to do it, I'm just guessing this will work), try unbinding it, rebinding it, unbinding it again, binding it directly to a spell in your spellbook, and binding it to the button you want. It was some random permutation of those actions that did it for me; maybe you'll have some luck.
0
I always overlook the obvious. Thanks :)
0
Don't mind doing it myself, just thought it would be nice to have that option in the core.
0
God I never even noticed that. All right, thanks for the tip. Just go ahead and ignore my babbling, then :)
I wasn't suggesting he change it to mine, I was illustrating why I'd like something like he did with the power element (( if(self.PostUpdatePower) then self:PostUpdatePower(event, bar, unit, min, max) end )) for the pvp element as well so the texture/text can be updated to ffa/pvp when the UNIT_FACTION event occurs. If you are saying that there is a way to do this from the layout (other than registering the UNIT_FACTION event myself), would you mind showing me how?
0
oUF:Spawn("raid", "raid_odd", "raid_odd") -- with style.raid_odd.attributes.groupFilter = "1,3,5,7"
oUF:Spawn("raid", "raid_even", "raid_even")
The needsHeader thing was just a flag to say whether or not this spawn would need a secure header set up for it, but is unnecessary as what you do by checking for the unit being "party" or "raid" is enough. (Like I said, I never really tried to implement this!) I was also thinking that maybe one would want to set up unique attributes for the other frames (party/focus/target/etc), but I didn't give any thought to how useful such a feature would actually be.
As for missing attributes, no, I'm not missing any I would use (if there are even others to use). I suggested a table just because it seemed easiest from a maintenance point of view: the user would specify whatever they wanted, and you'd just have to do a pairs() over the table and not worry about it.
0
1. pvp element
This is what I made before you did your own module. Maybe you can add a "PostUnitFaction" or "PostPVPUpdate" call to your :UNIT_FACTION() like you did with some of the other elements, too, so people can update the texture/text from the layout?
2. Level text.
Another idea. I made it specifically for my layout (hence the unit class) and didn't really test it (hence the "wtf" is still there). For me, seeing the level of my target on my unit frame is pretty crucial.
3. Generic raid headers. I never really got around to doing this myself, but what I was thinking was changing the table that you send to :RegisterStyle to be something more like this:
And then you'd have to change the oUF spawn and initobject methods to accommodate. Like I said, I never really got around to trying this, so it might not work as presented. The idea, though, was that you could specify arbitrary headers/attributes in the layout and make a raid header for, say, just tanks, or the whole group, or whatever the secure templates allow. And then you'd just call :Spawn(unit, name, key) (with a default value for key being 'default'), and the name field would be the name of the header (or frame if no header was present) in the form "oUF_"..name, which you could check in your layout function to determine how to set up the layout of the frame.
These are just some ideas to consider. If you don't want to do them because they are dumb/a pain in the ass, it's all good :) Thanks for the great mod.