After a little testing, playing around with BlizzFacade and trying to get everything just right while still keeping overhead low, I realized that you're right. This is a bad idea in general.
First of all, the only way to successfully maintain a border's colors is to actually hook into the SetVertexColor of each of those textures. That's NOT something LBF should be doing. That's a lot of excessive overhead that's already being done by the add-on.
Secondly, because of the nature of border colors, LBF shouldn't be interfering and risking breaking or causing havoc with the add-on.
If an author wants to include options to allow the user to customize those colors, they can incorporate that into their own add-on more readily and much more efficiently than LBF can.
That said, effective the next revision (when I get it finished and get around to committing it), LBF will no longer color the borders at all. It'll be up to the author to control that.
Simple, efficient, effective.
I don't know how I could I ever doubt you, oh great one! :P
Phanx, here's a patch for PhanxBuffs that should fix any issues. I've commented every edit so that you can see what I've done. It fixes both the LBF support and the buff "buttons" not updating when adjusting their size, etc, in PB's options.
I know the recent changes have been a hassle for ya, so I figured I'd help out. :p
No, border color options were removed. In order for LBF to maintain the color, it would have to hook every border texture to over ride it. It is now up to the add-on being skinned to color the border(s). You can request such a feature at the respective add-on's download page.
Anyhow, i have no intentions of writing skinning code of my own, and will send anyone whining about missing border colors your way =)
Just to be sure i'm not misunderstanding ..
Some skins come with their own border, that one can still be colored?
Default buttons don't even have a visual border, the green thing with items is basically overlayed on the icon. That was skinnable before? =P
Actually, Nev, that "green thing" is what LBF refers to as the border, since it's just an accenting texture. The "border" or "frame" you see around icons in various skins is the "Normal" texture. It hasn't changed.
What I was referring to as far as asking the author (in this case, you) in adding an option was adding an option to adjust the "green" color of the texture that's used to identify equipped items.
For the record, LBF attempted to skin it before, but every ActionButtonUpdate() call made the color revert back to the green color. So in order to maintain it, LBF would have to hook every one of those textures, which is way too much overhead. Since a button add-on is already doing updates, it wouldn't be much to just ad a line to set the color based on a SV setting.
And you're right, default buttons don't have the "frame" around them, that's why LBF uses the "Normal" texture for that. Because a skin author can actually create separate textures for various states and the engine will swap those automatically. Alternatively, they can do what I do and just tell LBF to not allow those swaps and use accenting textures for those states.
But to touch on that again, LBF calls the texture that gets colored on equipped items and debuffs the "Border" texture because that's what the default UI calls it. IE, ActionButton1Border, etc. :p
P.S. Nev, That ticket I posted that you fixed, I made a comment on it. Might want to check it out. :P
I would like to see a new optional key added to skins that BF will then add to the button, if the key is available - shape.
I myself prefer round skins and with the new spell flash alerts in 4.0 I am working on designing a round-button version of a spell flash alert. However, to display the proper square, round or other shaped spell alert, there needs to be a way to query the button to determine the intended shape of the skin by the skin designer. A index can then be added to the button's table such as button.__bfskin_shape = "[square|round|other]", or at the very least add a method to BF such as BF:GetShape() which returns the shape key for the button skin if available, nil otherwise.
I get emails about all comment updates.
But its irrelevant anyhow, that code is no longer being executed in the Cataclysm version, replaced by LibActionButton, which doesn't have any LBF special case logic. :)
Oh, and what Maul said would be a good idea. The new overlay thing only fits on square buttons, looks rather funny on round ones. ;)
Maybe the skin itself can switch around the overlay animation, instead of exposing that interface?
Would have to bundle the new animation with ButtonFacade, for example.
I've actually been trying to decide how to handle the flash alert frame. I'll post some details once I've had a bit more time to play with it. But I do realize that I'll have to package a default round version with ButtonFacade so had already intended on creating one as close as possible to the default one.
I modified Debuff Filter to work with Ace3 and ButtonFacade. Do skins do anything with the stack of the buff/debuff? I tried using the Count field, but skins will place it at the bottom center of the buff/debuff, not where I want it to be. So I just tell ButtonFacade to skip the Count field.
LibButtonFacade sets all of the layers (including the text layers) relative to the center of the button. Skins then adjust the position via offsets. Any calls to SetPoint for that layer will clash with LBF and cause the layer to change position on update, etc., which can be ugly.
Since it's only a text layer, you can set that layer to false in the ButtonData table if you need to retain control of the "Count" layer. That's really the only option but it may not look right with some skins.