Revision 339 should fix the issue with the Blizzard skin not showing up in the UI (BAD STORM!) and a few other minor issues.
I need some opinions on how to best go about supporting the new "Flash" frames. The problem is that they're created dynamically so I don't want to have to fool with hooking some internal function just to keep them updated. Not to mention, I'd have to figure out which group the button that's receiving the frame belongs to.
How about if I provide a method that allows the mod authors to pass the frames to LBF as they're created?
Something along the lines of:
LBF:SkinFlashAlertFrame({object},{LBFGroup})
This would probably work for LAB, as well. Of course, I'm still undecided on where to simply allow a specific "Shape" attribute (which I'd have to provide some default textures) or to actually allow skin authors to supply a texture for each part of the animation themselves. The latter seems the most logical, but meh.
Edit: I'll probably do something similar with the AutoCast layer. If only the Cooldowns were the same type of animation. /sigh
Been a long time user of this addon, and for the most part had no issues. But (yay, a BUT) I've found one....
I have one toon of every class, and if I set up a profile for each toon, and set the addon (using Pixelskin) to display the class color, when I change toons, all addons except BT4 decide to show a random alts class colored border.
For example: I log my druid. BT4 seems fine. Autobar displays the mage class color and SBF displays all white borders.
Any ideas?
I can manually reset them, but I have to do this every time I log an alt, and I'm an altoholic :/
ButtonFacade doesn't handle the border (the overlay for equipped items, etc) anymore. That's handled by the add-on. AutoBar is outdated and SBF doesn't hasn't been adjusted for the change, yet.
The latest revision adds a few features for skin authors to tweak their skins a bit more.
Text layers now accept the following attributes:
Font
FontSize
JustifyH
JustifyV
Those respective attributes will default to their original values if the value is not specified in the skin.
As an example, the text justification for each layer is now how it's defined by the default UI if not specified by the skin. The same is now also true of the position of those elements. This helps fix some issues but I imagine it'll cause a few new ones. We'll see.
Keep in mind that skins that aren't updated will have some oddly placed text until they're fixed, but I want to make sure it doesn't interfere with anything before I let it pass. If you want to test it out, you can check out the latest alpha of Apathy, as it's been updated to reflect those changes or simply use one of the default skins.
Does my addon have to use Ace3 to properly save ButtonFacade settings? Currently I don't use Ace3 and whenever I try to set my saved skin config with Group:Skin() on login, ButtonFacade resets the skin to default..
Well I wanted to have that basic thing answered first because posting my code wouldn't make sense if it would be required. Ok so lets start..
In the global namespace of my addon I'm doing this:
local LBF = LibStub('LibButtonFacade', true)
local bfButtons = {}
Then on Player login that:
if not nivBuffs_BF then nivBuffs_BF = {} end
bfButtons = LBF:Group("nivBuffs", "auras")
bfButtons:Skin(nivBuffs_BF.skinID, nivBuffs_BF.gloss, nivBuffs_BF.backdrop, nivBuffs_BF.colors)
LBF:RegisterSkinCallback("nivBuffs", self.BFSkinCallBack, self)
function nivBuffs:BFSkinCallBack(skinID, gloss, backdrop, group, button, colors)
nivBuffs_BF.skinID = skinID
nivBuffs_BF.gloss = gloss
nivBuffs_BF.backdrop = backdrop
nivBuffs_BF.colors = colors
end
nivBuffs_BF is added to the SavedVariables. Checking what is being saved, it contains the settings I picked in ButtonFacade (that would be BF_Serenity skin). Skinning also works good so far.
Now on reloadui / relog, nivBuffs_BF will be loaded correctly with what was saved. I checked that with the table browsing feature of LuaConsole (after commenting out the RegisterSkinCallback call). However, when the callback is active, LuaConsole tells me that the SkinID has been set to "Blizzard". It looks to me that BF set it back to default and called my SkinCallback function which then overwrites my config array with the default values.
Since updating to r342, on all skins other than Blizzard, the keybinding and/or macro names are outside the top and bottom of the button.
same
reverted back. I saw in the change log some new tags were added. But I made about 7 custom skins, and have no desire to go back and change all of them right now, lol.
if not nivBuffs_BF then nivBuffs_BF = {} end
bfButtons = LBF:Group("nivBuffs", "auras")
bfButtons:Skin(nivBuffs_BF.skinID, nivBuffs_BF.gloss, nivBuffs_BF.backdrop, nivBuffs_BF.colors)
LBF:RegisterSkinCallback("nivBuffs", self.BFSkinCallBack, self)
You have to register the callback before creating the group and/or skinning it.
In regards to the text layer changes, there were some issues that could not be resolved outside of leaving the alignment of the text layers where they were by default.
The changes make it so that skin authors can place the text anywhere, assuming that the know how to use height, width, justify and offset correctly.
P.S.
The change log specifically states that some skins will look bad until they've been updated to reflect those changes. Alphas are for testing purposes. If you're not going to read the change log to see what you're getting into, don't install them. Once they've been tested and I'm certain everything will go smoothly, I'll notify skin authors of the upcoming changes so that they can update their skins accordingly, prior to release.
On second thought, I'm going to leave some "old" code in for those skin authors who have a bit of a delay getting their skins updated. I'll probably remove this old code sometime after Cataclysm. But for authors who want to use and support the new features, you'll have to add a new key your skin table that will tell LBF that it's compatible with the new features. I haven't implemented it yet, but when I do, I'll let you know via the change log.
With the latest revision, the skin has to have the LBF_Version set to 40000 in order to use the new text attributes. Older skins without it will function as they previously did.
Hi,
I have written an addon and wanted to check something.
When I load Grid (which includes all the Ace Libraries) and then my addon, my addon's memory use is 85k.
When I load ButtonFacade and then my addon, my addon's memory use jumps to 1.3megs. It drops down again after about 20 seconds. There is not a single button in my addon; all my frames are type "frame".
I understand that when ButtonFacade loads first, it's loading the Ace libraries and will have an extra ~500k memory usage listed for itself. My question's really not about that. This 500k is the same regardless of whether I load my addon or not... It's the additional 1.3 Megs assigned to me that I'm wondering about.
Can you think of any conflict I might have made or? Heard this before?
Edit: I tried copying the Ace libraries so both had the same version, but it made no difference.
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. :|
Lol ok thanks.
It just seemed odd that any combination of addons, except for two specific ones, was 1.3 megs less. Grid and BF don't add it, grid and mine don't add it... the only combination that makes it is mine + Bf. But if you say it's ok, I'm not going to worry about it. :)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEdit. I had it fixed, just .. yeah. Ok. >.<
Edit: I've got more changes coming, so just use the latest alpha for now. Been working many hours. :(
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorI'll have to ask Kaelten if they are still active.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI need to replace/remove my keyboard cover. Hit tab, get tilde. /sigh
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI need some opinions on how to best go about supporting the new "Flash" frames. The problem is that they're created dynamically so I don't want to have to fool with hooking some internal function just to keep them updated. Not to mention, I'd have to figure out which group the button that's receiving the frame belongs to.
How about if I provide a method that allows the mod authors to pass the frames to LBF as they're created?
Something along the lines of:
LBF:SkinFlashAlertFrame({object},{LBFGroup})This would probably work for LAB, as well. Of course, I'm still undecided on where to simply allow a specific "Shape" attribute (which I'd have to provide some default textures) or to actually allow skin authors to supply a texture for each part of the animation themselves. The latter seems the most logical, but meh.Edit: I'll probably do something similar with the AutoCast layer. If only the Cooldowns were the same type of animation. /sigh
Been a long time user of this addon, and for the most part had no issues. But (yay, a BUT) I've found one....
I have one toon of every class, and if I set up a profile for each toon, and set the addon (using Pixelskin) to display the class color, when I change toons, all addons except BT4 decide to show a random alts class colored border.
For example: I log my druid. BT4 seems fine. Autobar displays the mage class color and SBF displays all white borders.
Any ideas?
I can manually reset them, but I have to do this every time I log an alt, and I'm an altoholic :/
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumText layers now accept the following attributes:
- Font
- FontSize
- JustifyH
- JustifyV
Those respective attributes will default to their original values if the value is not specified in the skin.As an example, the text justification for each layer is now how it's defined by the default UI if not specified by the skin. The same is now also true of the position of those elements. This helps fix some issues but I imagine it'll cause a few new ones. We'll see.
Keep in mind that skins that aren't updated will have some oddly placed text until they're fixed, but I want to make sure it doesn't interfere with anything before I let it pass. If you want to test it out, you can check out the latest alpha of Apathy, as it's been updated to reflect those changes or simply use one of the default skins.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIn the global namespace of my addon I'm doing this:
local LBF = LibStub('LibButtonFacade', true) local bfButtons = {}Then on Player login that:
if not nivBuffs_BF then nivBuffs_BF = {} end bfButtons = LBF:Group("nivBuffs", "auras") bfButtons:Skin(nivBuffs_BF.skinID, nivBuffs_BF.gloss, nivBuffs_BF.backdrop, nivBuffs_BF.colors) LBF:RegisterSkinCallback("nivBuffs", self.BFSkinCallBack, self)All my buttons are being added to the group with:
bfButtons:AddButton(btn, { Icon = btn.tx, Cooldown = btn.cd } )And the skin change callback function:
function nivBuffs:BFSkinCallBack(skinID, gloss, backdrop, group, button, colors) nivBuffs_BF.skinID = skinID nivBuffs_BF.gloss = gloss nivBuffs_BF.backdrop = backdrop nivBuffs_BF.colors = colors endnivBuffs_BF is added to the SavedVariables. Checking what is being saved, it contains the settings I picked in ButtonFacade (that would be BF_Serenity skin). Skinning also works good so far.
Now on reloadui / relog, nivBuffs_BF will be loaded correctly with what was saved. I checked that with the table browsing feature of LuaConsole (after commenting out the RegisterSkinCallback call). However, when the callback is active, LuaConsole tells me that the SkinID has been set to "Blizzard". It looks to me that BF set it back to default and called my SkinCallback function which then overwrites my config array with the default values.
same
reverted back. I saw in the change log some new tags were added. But I made about 7 custom skins, and have no desire to go back and change all of them right now, lol.
Same here, had to revert to the previous version. At first I thought it's Bartender being buggy, but seems it was Button Facade.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou have to register the callback before creating the group and/or skinning it.
In regards to the text layer changes, there were some issues that could not be resolved outside of leaving the alignment of the text layers where they were by default.
The changes make it so that skin authors can place the text anywhere, assuming that the know how to use height, width, justify and offset correctly.
P.S.
The change log specifically states that some skins will look bad until they've been updated to reflect those changes. Alphas are for testing purposes. If you're not going to read the change log to see what you're getting into, don't install them. Once they've been tested and I'm certain everything will go smoothly, I'll notify skin authors of the upcoming changes so that they can update their skins accordingly, prior to release.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumExample:
LBF:AddSkin("Skin Name",{ LBF_Version = 40000, Backdrop = { ... }, ... etc }I have written an addon and wanted to check something.
When I load Grid (which includes all the Ace Libraries) and then my addon, my addon's memory use is 85k.
When I load ButtonFacade and then my addon, my addon's memory use jumps to 1.3megs. It drops down again after about 20 seconds. There is not a single button in my addon; all my frames are type "frame".
I understand that when ButtonFacade loads first, it's loading the Ace libraries and will have an extra ~500k memory usage listed for itself. My question's really not about that. This 500k is the same regardless of whether I load my addon or not... It's the additional 1.3 Megs assigned to me that I'm wondering about.
Can you think of any conflict I might have made or? Heard this before?
Edit: I tried copying the Ace libraries so both had the same version, but it made no difference.
Thanks.
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. :|
It just seemed odd that any combination of addons, except for two specific ones, was 1.3 megs less. Grid and BF don't add it, grid and mine don't add it... the only combination that makes it is mine + Bf. But if you say it's ok, I'm not going to worry about it. :)