There's no conflict. There's not even a problem. What you're seeing is the expected result of running embedded libraries. If you have 10 addons that all embed the same 5 libraries, then (assuming they all embed the same revision of each library) the library-related memory usage of all 10 addons are attributed to whichever one's copies of those libraries loaded first.
Each time another addon loads, its copy of each library is loaded into memory, and then compared against the currently existing instance of that library, and then one of the copies is discarded. (This is what LibStub does, by the way.) So, during loading, you'll see your memory use jump up and then drop down each time another copy of the same library is loaded and then discarded and garbage-collected.
On a side note, I wish I had a dollar for every time someone asked this question or some variation of it. Even if it only included this particular thread. :|
Of course, that's assuming we're talking about the same "Border" object. Which, again, refers to the accenting "border" that's used to color the edges of equipped items, debuffs, etc. The default UI refers to this in the same manner.
I'm referring to whatever is affected when the LBF:SetBorderColor(...) function is called. My buttons do set their ButtonData.Border to false, do not have any regions that could be mistaken for a border in the sense that ButtonData.Border refers to, and do not have global names for themselves or for any of their children/regions, so by your explanation, calling LBF:SetBorderColor(...) should do nothing, but this isn't the case.
The Group:AddButton() method will still accept the third parameter, "Type". However, if this value is nil or false, LBF will do nothing with the color of the texture, which will allow the texture to retain its existing coloring.
Does this also mean that when the user changes the "Normal" color in the ButtonFacade options, it won't change the vertex color of the "Normal" texture object on my button?
This also goes back to a question I asked previously that I don't think you answered. Which type should I specify for my buff buttons? I do not want their borders colored by their type, or colored when the user mouses over them, etc. Their borders should always be colored according to the "Normal" color the user chose in the ButtonFacade options.
... the GUI willl not display border options for any group unless at least one button from that group has its "type" set.
By "border options" do you mean "color options" or "any options"? Even if LBF isn't managing a button's border colors, the GUI should still allow the user to choose a skin (eg. Entropy, Serenity, ThinSquare, etc) and adjust the gloss opacity.
If the ButtonData.Border value is set to false, LBF ignores the region unless there's a "Border" object registered in the global namespace. In which the texture is set to an empty string and the object is hidden. If you're still seeing that texture, then either the default UI is doing something with it or your code is because LBF isn't.
Since my buttons aren't based on templates, I sincerely doubt that the default UI is doing anything with them, and my code does not create a border region or place any buttons or button regions in the global namespace.
The screenshots I've posted previously clearly demonstrate that LBF is not behaving the way you describe; you're welcome to look through my code and/or the default UI code and prove me wrong, but as it stands, your description of LBF's functionality does not match LBF's actual functionality, as I can show with a mere 2 lines of code.
I'm sorry, but if you're seeing "any add-on that supports ButtonFacade should remove its border coloring feature" in what I posted, you need to work on your interpretation skills. That statement is nonsense. I simply stated that the feature isn't required. If the add-on supports it, they can code around it. If it doesn't, ButtonFacade can offer that feature.
This statement you made a few posts back seems to contradict you:
There's NO reason for a buff add-on to have to provide a means for custom coloring when a skinning add-on that it supports can do it in a manner that's more convenient for the user.
No, the feature isn't required. However, neither is ButtonFacade required. Most addons are not written specifically for ButtonFacade. They are written as standalone, feature-complete addons, and support for an optional skinning addon is added after the fact.
If you said "no buff addon that supports ButtonFacade should include its own texture skinning options", I'd probably agree with you. When you're talking about functionality that's present in the default UI (coloring icon borders by debuff type) and saying "no buff addon that supports ButtonFacade should give users any control over this functionality", I just can't agree with you. I respect the time and effort you've put into ButtonFacade, but no matter how much time you've spent coding this particular functionality, I just don't think it belongs there.
If that is the effect you're getting, then something else is probably resetting and reshowing the texture. As I've said, when the layer is set to false, the texture is set to an empty string and the layer is hidden. If another add-an manipulates the object after the fact, I have no control over it.
The effect occurs when PhanxBuffs and ButtonFacade are the only addons enabled. We went over this in excruciating detail a few pages back; you even said yourself that you could see the difference. I'm not sure why you don't seem to remember any of this.
But that still doesn't make customizing the debuff colors a requirement for that add-on.
See, this is exactly what I'm objecting to. You're saying that any addon that supports ButtonFacade should remove features, or not include them in the first place if they're newly being written, because ButtonFacade provides them. ButtonFacade has always been optional and strictly cosmetic. It was never intended to replace actual functionality within addons, and it was never intended that addons should rely on it to provide non-cosmetic features.
The default buff buttons never change "types". Though they may reuse the button for another debuff of the same type. I never delved that much into it.
You can clearly see in BuffFrame.lua from the default UI that debuff buttons do change which type of debuff they display. There are even comments labeling each section of code, including the lines that check the type of debuff currently being displayed and change the overlay texture color and colorblind text string accordingly.
There's NO reason for a buff add-on to have to provide a means for custom coloring when a skinning add-on that it supports can do it in a manner that's more convenient for the user.
There are so many problems with this statement that I'm not even sure where to start.
You seem to be operating under the assumption that everyone uses ButtonFacade, when this is simply not the case, or even close to the case. Most people I know don't use any button-skinning addon at all, and have no interest in skinning buttons or any other part of their UI. Even among people who do care about the aesthetics of their UI (eg. people who post screenshots of their UI in "show off your UI" threads) there's a good number of people not using a button-skinning addon. On top of that, ButtonFacade isn't the only game in town. I see a growing number of addons offering support for rActionButtonStyler, and have gotten several requests to add support for it in PhanxBuffs.
(As an aside, I probably had an equal number of requests for BF support and rABS support for PhanxBuffs; the only reason I added BF support first was because I was already familiar with BF and it had extensive documentation and a developer who was responsive to questions, whereas I know next to nothing about rABS and there is no documentation on its download page.)
Following from that, should users be required to use ButtonFacade in order to use a buff mod? Should users be required to use ButtonFacade in order to customize the colors used by a buff mod? I'd strongly answer "no" to both of those questions. ButtonFacade and its predecessor, cyCircled, were always intended to be optional eye candy; they were never meant to replace actual functionality in addons.
If you agree that ButtonFacade should not be a requirement to use a buff mod or a requirement to configure functions of a buff mod that are not specific to ButtonFacade, then how can you possibly believe that no buff mod that supports ButtonFacade should provide options for changing debuff colors?
And really, how many buff add-ons actually recycle the buttons themselves and use them for other buffs/debuffs/types? In the typical buff/debuff add-on, once the button is created, it remains the same type until the UI reloads and it's GC'd.
Creating a new button for every new buff/debuff is quite possibly the worst addon programming idea I've ever heard. If there is an addon that's doing this, please, tell me which one so I can tell its author what a horrible, horrible thing they are doing.
My buff addon, as well as every other buff addon whose code I've looked through, creates new buttons only when more debuffs are shown at a one time than were previously shown at any one time. Buttons are assigned a fixed position when they are created (or when the user changes layout settings), and only their conntents (such as the icon, and internal key/value pairs identifying the debuff they are currently displaying) are changed as the list of debuffs present on the unit changes.
In a very "busy" situation such as an arena match where many debuffs are being applied and removed, a single button object could potentially change which type of debuff it is displaying 5 times a second, since that's the interval to which I throttle my response to the UNIT_AURA event for a single unit, and since I display buffs in order by their duration, not by the internal index Blizzard assigns them. In a typical raid encounter, a single button object will probably only change which type of debuff it's showing once every few seconds at most, but it still changes.
The primary point being that authors don't have to or need to bother with the colors because LBF handles it.
Yet authors still have to "bother" with the colors, unless they are willing to (a) make ButtonFacade a required dependency for their addon, or (b) remove or reduce functionality for users without ButtonFacade.
Even the default UI colors debuff borders (again, general layman's sense of the word "border") by debuff type. Do you think Blizzard "shouldn't bother" with this because users can install BlizzFacade?
My buttons most certainly are recycled, as should be the buttons or other frame objects in any well-written addon. As I said before, if there is a buff addon that's creating a new frame every time a buff is applied, the author of that addon is totally clueless and is doing it very, very wrong.
If I can do something that will improve ButtonFacade in my eyes, I'm going to. I'll try do it with as little hassle as possible for authors, but there may be times when someone disagrees with my methods. In that case, they can offer constructive feedback and I'll take into consideration.
I don't have a problem changing working code because you want to change the API, whether it's because you think a new API would be more efficient, or simply because you want to name the API functions after your grandma's cats.
What I do have a problem with is the fact that you're assuming that everyone uses ButtonFacade, and advocating that authors remove functionality from their addons and depend on ButtonFacade to provide that functionality, especially when, in the years since cyCircled and ButtonFacade were conceived and written, their original authors have always kept them within the realm of providing only optional aesthetic enhancements.
Anyway, your last statement implies very strongly that you don't consider my feedback to be "constructive", so I'll stop here. There's not really anything else to say. I've clearly explained my concerns about the direction you are taking ButtonFacade. If you want to consider what I've said, you can. If you don't, you won't, and there's nothing more I can say that will change your mind. The only thing I can do is keep an eye on ButtonFacade's development, and either update my addon to support the new versions, or remove support for it altogether.
I think the "border" you're referring to is actually the "Normal" texture (Button:GetNormalTexture()), which is the border-ish overlay on top of the icon. There's never a reason to color this. That's what the "Border" layer is for. :p
I was using "border" in the general sense, to refer to the visible texture(s) displayed around the edges of buttons in-game that most people look at and call a border.
... set the ButtonData.Border element to false. This will cause LBF to hide the texture and ignore it.
Unfortunately this doesn't work the way you describe; if you've forgotten our previous exchange with regard to strong colors vs. washed-out colors, refer to the last page in this thread with screenshots. PhanxBuffs does set ButtonData.Border to false; if this caused LBF to hide the texture on that layer and ignore it, then logically, coloring this layer via the SetBorderColor API should have no effect. As my previous screenshots and posts illustrate, this is very much not the case.
Right, but what you were complaining about was an alpha. We all know that alphas are rough cuts of what we're trying for. Testing and providing feedback is great, but don't get bent out of shape when it's not even finished yet. :p
Maybe, but when you say "update or break" when there's not a complete API to update to, you shouldn't be surprised when people complain that they can't update.
I'm thinking of possibly adding some more types. This may be useful in the future, but I do know that some of the Paladin stuff is considered "Holy". In this case, I could add that as a type, with maybe a yellow border color.
Eh, all of the special typing stuff still just seems like overkill. "Action" and "NonAction" seem like all you need. As I pointed out before, any addon dealing with debuffs is already updating other parts of the button when a debuff changes, so manually setting the border color is almost no extra effort. For a "Paladin Holy" button, there's even less work; you'd just set the border color once when you create the button, since an ability that's "holy" when the button is created is always going to be "holy".
You'll probably tell me I'm doing it wrong, but from what I've seen so far I'll most likely just register all of PhanxBuff's buttons as "Special" buttons and continue manually setting the border colors like I am now. Seems like less work than changing the button's type and reskinning the whole group.
The only buff buttons that even have borders are Temporary Enchants.
Maybe we're talking about different things here, but every buff addon I've ever seen that supports ButtonFacade has borders on the buff icons as well as the debuff and temp enchant buttons. Even your own BlizzFacade puts borders on buff icons.
My question was: I have a buff button. I want to skin it with ButtonFacade. I do not want the button's border colored by the buff's type (eg. Magic). What kind of button should I tell ButtonFacade this is? What kind of button will you be tellling ButtonFacade the Blizzard buff buttons are in BlizzFacade?
... I specifically stated that I haven't implemented the API to change the border color on the fly.
Yes, I read and understood that, and that's precisely why I complained about the fact that you're breaking compatibility by introducing a new API when a feature used by many addons has not yet been reimplemented.
... the idea is that the add-on you're referring to would simply call a method that changes its type internally and applies the new color. Not a big deal. Lastly, there's no reason to do anything with any of the other textures. The borders are there to fill the role of providing a means for recognition for varying attributes.
I guess I just don't understand what was so horrible about the simple SetBorderColor API that existed previously. It was a universal solution that worked for everyone. Pretty much any addon that changes the "contents" of a button has some code to do that, so throwing a quick SetBorderColor line in the same chunk of code was easy, straightforward, and intuitive. Having to change the button's registered type in addition to that just adds more code and more work.
Reskinning the whole group, and modifying LBF's "special" values, seems like an overkill method of changing the border color on one button...
Also, what would be the recommended value of a buff button where the border color should never change?
Breaking compatibility in general seems like a bad idea, especially since a key part of the API isn't even finished yet. The action button addon I use, for example, changes a button's border color if the buff or debuff caused by the spell on the button is currently active on the appropriate unit (eg. the Curse of Agony button gets a special border color if I'm targeting a mob with my Curse of Agony active on it). Actually, this is a perfect example -- this button is an action button, and should normally be colored as such, but sometimes the addon wants to override the "default" coloring with a special color. I don't see any way in the new API for that to happen, without using the "Special" type and managing action button pushed/highlight/disabled/etc states manually.
SBF has never correctly supported ButtonFacade; it's always been a half-assed hack that breaks any time anything in ButtonFacade changes. Satrina has already stated that the next major version of SBF will include proper ButtonFacade support, but I haven't seen any ETA on when that might be available.
And as far as the alpha goes, check the "red" color in your debuff file. it's 1,0,0. No alpha. :p
What's in Debuffs.lua doesn't matter, because if ButtonFacade is enabled, then SkinSupport.lua overwrites the border coloring function originally defined on each button with:
f.SetBorderColor = function(f, r, g, b, a)
if a == 0 then
LibButtonFacade:SetBorderColor(f, 1, 1, 1, 0)
LibButtonFacade:SetNormalVertexColor(f, 1, 1, 1, 1)
LibButtonFacade:SetBorderColor(f, r, g, b, a)
LibButtonFacade:SetNormalVertexColor(f, r, g, b, a)
The functional effect is that debuffs with a dispel type have their ButtonFacade borders colored, but "red" debuffs have their borders reset to the user's default colors (since that's what hiding the Border layer and setting the Normal layer to white does, as far as I can visibly determine). :p