Firstly, I adore this mod. One thing I've noted, however, is that changing skins do not "save". Insomuch as I'll set a skin, it will change, and then when I log out and log back it, it reverts to "Blizzard" skin.
Rhaethe, please at least scan over the last few pages of the thread, or read the in-game settings GUI, before you ask something that's been asked and answered and explained so many times already. I'll even quote myself:
ButtonFacade does not store any settings related to your skinning preferences for addons. Each addon is responsible for maintaining its own settings. ButtonFacade is merely a GUI to allow you to configure all addons in one place. If you drill down to the most granular level in the ButtonFacade GUI, it will show you the correct settings for that button or group of buttons, because it can query the addon and ask "hey, you registered Group X with me, what color is it right now".
However, when you're looking at the top level, where you can change something and have it apply to everything in all addons, ButtonFacade does not query every addon for information about every button group and try to decide what to show at the top level. If your settings were all the same, it should obviously show you those, but what if the settings aren't all the same? It wouldn't make sense to show anything at all. For example, I use the same settings for everything except Satrina Buff Frames; for SBF, I change the "equip" color to fully transparent, because if I don't, it will cover up the debuff type border coloring in that addon.
I don't use Dominos, so I don't know how it registers with ButtonFacade, but I know Opie registers a single "Opie" category. If you type "/bf" and the GUI that opens is displaying default settings, click on "Opie" in the left column. Your actual settings as they apply to Opie will then appear.
Long story short: this isn't a problem at all, but rather a consequence of a system that allows different settings for different addons or even different parts of the same addon.
If you are using AddonX, and when you log back in, the visual appearance of AddonX has actually reverted, that is a problem you should notify the author of AddonX about, but if you are simply concerned about the fact that the GUI that comes up when you type "/bf" lists default values after you reload your UI, the above applies 1000%.
Actually, I had read that. However, an update had been made since that had been posted, and it wasn't clear to me if anything had changed or not. Insomuch as the skins on my actionbar (modified by Dominos addon) used to retain the ButtonFacade skin. After the update to BF, not so much.
In any event, I ended up figuring out another way to skin my actionbar buttons in the fashion I wanted, so it's all good.
No, that hasn't changed, and never will. It's just not practical.
Let's say you have three skins installed (X, Y, and Z) and four addons installed that can be skinned (A, B, C, and D). Let's say you've skinned them as A:X, B:Y, C:Y, and D:Z. What would you suggest the top-level UI show as the current settings? X because it's used by the alphabetically first addon? Y because it's used by the most addons? What if you changed addon D to use skin X? Then there's no skin winning numbers-wise. What if addon B has four components that can be skinned separately? Then you're looking at A:X, B1:Y, B2:Y, B3:X, B4:Z, C:Y, and D:Z.
The more addons and addon components you add to the system, the less it makes any sense for ButtonFacade to try to pick something to show at the top level. Therefore, it doesn't try to pick something, and just shows you the default settings. If you want to see the current settings for something, select that specific something from the AddOns menu.
Since there is a default skin option for ButtonFacade why can't you just build a function that lets you enable the default skin at startup?
If you don't I need to "quick and dirty" run the corresponding ButtonFacade functions that set the default skin in my own little addon at startup.
I've got this problem with Yata and the latest update for Yata was 5months ago.
Sure its easy to say "they need to support my addon in order to work correctly" but hey, its your addon, its a decorator/wrapper that just modifies the other addons so pleeeeeaaaase save the options.
This would be a Dominos issue. You need to ask the author of Dominos to add ButtonFacade support for the bag buttons in addition to the action buttons.
I asked Tuller for support to skin the bag button but he answered that ButtonFacade does not support "non action button objects" so could you make ButtonFacade support those too please. -Strongbow-
Firstly, I adore this mod. One thing I've noted, however, is that changing skins do not "save". Insomuch as I'll set a skin, it will change, and then when I log out and log back it, it reverts to "Blizzard" skin.
I'm wondering if I have a setting off somewhere?
Thanks for any help :)
You can make a macro and run it on startup or put it somewhere to autoexecute
/script local LBF = LibStub("LibButtonFacade"); LBF:Group():Skin("Caith", 0.5, true);
Caith is my skin, 0.5 is my gloss level (0-1) and true is backdrop (true or false)
Since there is a default skin option for ButtonFacade why can't you just build a function that lets you enable the default skin at startup?
BF is designed around the idea that a user gets to select their skin. If they don't select a skin for a given addon (or globally), no skin is applied. This is intentional in that someone might not want a particular addon skinned. Forcing a default skin onload will not happen.
Sure its easy to say "they need to support my addon in order to work correctly" but hey, its your addon, its a decorator/wrapper that just modiefies the other addons so pleeeeeaaaase save the options.
So, if someone's addon doesn't support a library that has features you want, it should be up to the library author to fix that?
Technically, BF does not modify other addons. it provides an API for the addon to modify itself. BF is a GUI for the LBF library. Nothing more. It will never save the skin settings/options itself. That's up to the addon.
I asked Tuller for support to skin the bag button but he answered that ButtonFacade does not support "non action button objects" so could you make ButtonFacade support those too please.
BF supports a variety of button templates. He could simply use one of those for the bag button. Have him look at BT4. /shrug
You can make a macro and run it on startup or put it somewhere to autoexecute
Why do you need to see a selected skin in the global panel of the options window? If you want to know what addon is skinned with what skin, select the addon. How is that difficult?
So, if someone's addon doesn't support a library that has features you want, it should be up to the library author to fix that?
Technically, BF does not modify other addons. it provides an API for the addon to modify itself. BF is a GUI for the LBF library. Nothing more. It will never save the skin settings/options itself. That's up to the addon.
So it went from a real addon like cyCircled was to a library.. no matter if BF has something to do with cyCircled, its still the same idea, setting up skins for bars.
Sure with that design of the library you wanted to do everything neat and beautiful and hand over the responsibility to the addon authors to keep BF small. But it's not that nice everytime, a lot of addons are not maintained anymore but still work and therefore BF does not work very well but it works.
(I had the same debate about who is responsible for fixing bugs between applications and graphics drivers, as you can see you need to download ~100 MB graphics drivers because of tons of bugfixes for games you don't even play)
BF is designed around the idea that a user gets to select their skin. If they don't select a skin for a given addon (or globally), no skin is applied. This is intentional in that someone might not want a particular addon skinned. Forcing a default skin onload will not happen.
BF supports a variety of button templates. He could simply use one of those for the bag button. Have him look at BT4. /shrug
Why do you need to see a selected skin in the global panel of the options window? If you want to know what addon is skinned with what skin, select the addon. How is that difficult?
I was looking for a solution to my problem and I didn't think about people using different skins (which is not that common I guess). I found a solution and I did not dig further, but you are right, instead of globally reapplying the skin I now do it for the addon that does not set it itself:
/script local LBF = LibStub("LibButtonFacade"); LBF:Group("Yata"):Skin("Caith", 0.5, true);
Sure with that design of the library you wanted to do everything neat and beautiful and hand over the responsibility to the addon authors to keep BF small.
Actually, it was to allow addon authors to have more control over how their addon was skinned and even whether or not it was skinned. Forced skinning was a bad thing.
Additionally, if BF did the actual skinning, it would be up to BF's author (me, in this case), to update plug-ins for every single mod. Thanks, but no thanks.
But it's not that nice everytime, a lot of addons are not maintained anymore but still work and therefore BF does not work very well but it works.
LBF's api has not changed at all. So any addon that supported BF will still support it. If it breaks, then it's either the authors responsibility to fix it or the user's responsibility to move on to something that's up to date. LBF is doing what it's supposed to: Provide a button-skinning API.
(I had the same debate about who is responsible for fixing bugs between applications and graphics drivers, as you can see you need to download ~100 MB graphics drivers because of tons of bugfixes for games you don't even play)
Apples/oranges. Nothing we've discussed is a bug. At least on BF's end. LBF provides an API. If authors can't use it right or it wasn't implemented correctly, it falls completely on the addon author to fix it.
You and I can debate this all day. But the reality is that I'm currently maintaining BF and I say that the current implementation is sufficient and that it's up to the addon authors to implement things correctly.
I found a solution and I did not dig further, but you are right, instead of globally reapplying the skin I now do it for the addon that does not set it itself:
I'm still trying to figure out why you need that. If YATA is not skinning itself onload, why not simply fix it (YATA) so others can benefit as well? If you're just doing it for the config display, then, well, less OCD please. :p
And the Yata portion of the BF config window will *always* say what skin it is using - it gets this information from Yata. It is only the global part of the config that doesn't keep this information because of different addons using BF that may be using different skins. This has already been talked about 20 times in this thread.
I'm still trying to figure out why you need that. If YATA is not skinning itself onload, why not simply fix it (YATA) so others can benefit as well? If you're just doing it for the config display, then, well, less OCD please. :p
I need it because Yata does not work the way you want it to work.
I'm not the author of Yata, I just wanted to help people posting in this thread having the problem that their addon was not skinned on startup.
And since you keep your opinion this is the only thing I can offer them... and no I'm not gonna fix all addons that have problems, I'm lazy as well ;)
I need it because Yata does not work the way you want it to work.
I'm not the author of Yata, I just wanted to help people posting in this thread having the problem that their addon was not skinned on startup.
And since you keep your opinion this is the only thing I can offer them... and no I'm not gonna fix all addons that have problems, I'm lazy as well ;)
Just write a plugin for Yata if you want fix it, its not a librarys job to make sure addons implement it correctly.. its the addons job to make sure of that.
Thank you for your willingness to help others. It's just that the point is that that is a bug in YATA, *not* in ButtonFacade.
LibButtonFacade was created so that authors could control how their addons get skinned, they didn't have to go in and submit patches or touch the code of the skinning addon, nor did the author of the skinning addon have to keep up-to-date on every addon with buttons or when code changed in those addons, and also so that users didn't have to have useless code for 20 different addons when all they used was one.
ButtonFacade really is *better* than cyCircled, for those reasons. And the authors agreed (at least most did), which is why they switched. It isn't ButtonFacade's place to fix bugs with other addons in its code.
I asked Tuller for support to skin the bag button but he answered that ButtonFacade does not support "non action button objects" so could you make ButtonFacade support those too please. -Strongbow-
There are many addons that support ButtonFacade on "non action button objects". Tuller is wrong.
But it's not that nice everytime, a lot of addons are not maintained anymore but still work and therefore BF does not work very well but it works.
And the beauty of the system as it exists now is that BF support doesn't even need to be in the addon itself. If Yata isn't being maintained by its author and nobody else is willing to step up and add BF support (anyone can commit to its WowAce SVN repository), just write a third-party plugin. Look at ButtonFacade_ItemRack for an example.
(I had the same debate about who is responsible for fixing bugs between applications and graphics drivers, as you can see you need to download ~100 MB graphics drivers because of tons of bugfixes for games you don't even play)
In that case, the bug fixes are usually added to the graphics drivers because the applications are adhering to the published standard, and the graphics drivers have bugs in their standards support. The correct solution is indeed for the graphics driver to be updated with the fixes. Asking application developers to be aware of and account for every bug in every graphics driver every user might be using ever is simply ridiculous.
Also, if you don't want to download updates that don't apply to you, read the changelog before you download.
I was looking for a solution to my problem and I didn't think about people using different skins (which is not that common I guess).
Most people probably do not use different skins, but rather different settings for the same skin on different addons. For example, due to the way Satrina Buff Frames handles debuff highlighting, I need to set the skin's highlight color to 0% opacity in order for things to look right... but I do not want invisible highlights on my other addons.
Generally speaking, you're seeing a problem where there is no problem. The settings that are displayed on the main/global panel have nothing to do with any addon. If an addon isn't saving its skin settings correctly, that is not an issue with ButtonFacade, and would not be resolved by ButtonFacade showing something different on the global settings panel. The only thing ButtonFacade could do would be to force all addons to reapply their individual settings... which still would not help if the addon isn't saving its settings. Your "solution" is the equivalent of opening the config window and using the global panel to bulldoze all existing settings and overwrite them with your new choices. Adding this behavior to ButtonFacade would be a horrible thing for most users, as it would essentially destroy the system's ability to skin different addons and different parts of addons differently. It only solves your "problem" because you're using an addon that doesn't support the established API correctly. The correct solution would be to fix that addon, not ask for new behavior in ButtonFacade that would totally break the system.
I was wondering if someone here who better knows the inner workings of ButtonFacade might be able to take a look at FacadeBuffs? It's been half broken for a while now (last update on Curse looks to have been 6 months ago, and for all intents and purposes appears to be abandoned). I've tried looking at it and comparing with another mod that makes use of BF, but don't really seem to know enough to make any progress with it yet.
It loads without errors, however buff & debuff icons are not skinned, while temporary enchants still work properly. Drilling down to the individual group settings in the BF options seems to indicate it's still set to the Caith skin I usually use, so would appear that it's not properly applying the settings on load. Changing anything in the FacadeBuffs section in the BF options or the individual groups below does not seem to affect it, however changing the global BF options does... and it continues working fine until next login.
I apologize if this question has been asked (but this thread is 70 pages long now >.<)
I am adapting my mod to use ButtonFacade and so far it's been pretty easy. My issue is that my groups don't show up in the Button Facade config. I only have a heading for the mod itself.
The groups appear to be working properly, my skin callback gets called for each one, and the settings are being saved and restored properly. I just don't have the option of configuring them individually.
Here are some code snippets:
local LBF = LibStub("LibButtonFacade")
-- in initialize function
-- buttonfacade callback
if LBF then
LBF:RegisterSkinCallback('ButtonTimers', ABT:OnSkin(), self)
end
end
-- Button Facade Callback
function ABT:OnSkin(skin, gloss, backdrop, group, button, colors)
if group then
ABT.db.char["buttonFacade"..group] = {skin, gloss, backdrop, colors}
end
end
-- creating buttons
if LBF then
LBF:Group('ButtonTimers', group):AddButton(button)
end
end
if LBF then
local bfOptions = ABT.db.char["buttonFacade"..group]
if bfOptions then
LBF:Group('ButtonTimers', group):Skin (unpack(bfOptions))
end
end
You're actually calling the function ABT:OnSkin() when that line is run, and registering its return value (if any) to the callback. I'm assuming you want to register the function itself to the callback, in which case you should be doing this:
(I'm also assuming that "self" and "ABT" are the same thing in that line's scope, so using one or the other exclusively is more consistent and readable.)
Well this is wrong:
You're actually calling the function ABT:OnSkin() when that line is run, and registering its return value (if any) to the callback.
That's odd, the OnSkin function is being called when I modify the skin. I wonder how it's working?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Firstly, I adore this mod. One thing I've noted, however, is that changing skins do not "save". Insomuch as I'll set a skin, it will change, and then when I log out and log back it, it reverts to "Blizzard" skin.
I'm wondering if I have a setting off somewhere?
Thanks for any help :)
If you are using AddonX, and when you log back in, the visual appearance of AddonX has actually reverted, that is a problem you should notify the author of AddonX about, but if you are simply concerned about the fact that the GUI that comes up when you type "/bf" lists default values after you reload your UI, the above applies 1000%.
In any event, I ended up figuring out another way to skin my actionbar buttons in the fashion I wanted, so it's all good.
Let's say you have three skins installed (X, Y, and Z) and four addons installed that can be skinned (A, B, C, and D). Let's say you've skinned them as A:X, B:Y, C:Y, and D:Z. What would you suggest the top-level UI show as the current settings? X because it's used by the alphabetically first addon? Y because it's used by the most addons? What if you changed addon D to use skin X? Then there's no skin winning numbers-wise. What if addon B has four components that can be skinned separately? Then you're looking at A:X, B1:Y, B2:Y, B3:X, B4:Z, C:Y, and D:Z.
The more addons and addon components you add to the system, the less it makes any sense for ButtonFacade to try to pick something to show at the top level. Therefore, it doesn't try to pick something, and just shows you the default settings. If you want to see the current settings for something, select that specific something from the AddOns menu.
If you don't I need to "quick and dirty" run the corresponding ButtonFacade functions that set the default skin in my own little addon at startup.
I've got this problem with Yata and the latest update for Yata was 5months ago.
Sure its easy to say "they need to support my addon in order to work correctly" but hey, its your addon, its a decorator/wrapper that just modifies the other addons so pleeeeeaaaase save the options.
I asked Tuller for support to skin the bag button but he answered that ButtonFacade does not support "non action button objects" so could you make ButtonFacade support those too please. -Strongbow-
You can make a macro and run it on startup or put it somewhere to autoexecute
/script local LBF = LibStub("LibButtonFacade"); LBF:Group():Skin("Caith", 0.5, true);
Caith is my skin, 0.5 is my gloss level (0-1) and true is backdrop (true or false)
So, if someone's addon doesn't support a library that has features you want, it should be up to the library author to fix that?
Technically, BF does not modify other addons. it provides an API for the addon to modify itself. BF is a GUI for the LBF library. Nothing more. It will never save the skin settings/options itself. That's up to the addon.
BF supports a variety of button templates. He could simply use one of those for the bag button. Have him look at BT4. /shrug
Why do you need to see a selected skin in the global panel of the options window? If you want to know what addon is skinned with what skin, select the addon. How is that difficult?
Sure with that design of the library you wanted to do everything neat and beautiful and hand over the responsibility to the addon authors to keep BF small. But it's not that nice everytime, a lot of addons are not maintained anymore but still work and therefore BF does not work very well but it works.
(I had the same debate about who is responsible for fixing bugs between applications and graphics drivers, as you can see you need to download ~100 MB graphics drivers because of tons of bugfixes for games you don't even play)
I was looking for a solution to my problem and I didn't think about people using different skins (which is not that common I guess). I found a solution and I did not dig further, but you are right, instead of globally reapplying the skin I now do it for the addon that does not set it itself:
/script local LBF = LibStub("LibButtonFacade"); LBF:Group("Yata"):Skin("Caith", 0.5, true);
Actually, it was to allow addon authors to have more control over how their addon was skinned and even whether or not it was skinned. Forced skinning was a bad thing.
Additionally, if BF did the actual skinning, it would be up to BF's author (me, in this case), to update plug-ins for every single mod. Thanks, but no thanks.
LBF's api has not changed at all. So any addon that supported BF will still support it. If it breaks, then it's either the authors responsibility to fix it or the user's responsibility to move on to something that's up to date. LBF is doing what it's supposed to: Provide a button-skinning API.
Apples/oranges. Nothing we've discussed is a bug. At least on BF's end. LBF provides an API. If authors can't use it right or it wasn't implemented correctly, it falls completely on the addon author to fix it.
You and I can debate this all day. But the reality is that I'm currently maintaining BF and I say that the current implementation is sufficient and that it's up to the addon authors to implement things correctly.
I'm still trying to figure out why you need that. If YATA is not skinning itself onload, why not simply fix it (YATA) so others can benefit as well? If you're just doing it for the config display, then, well, less OCD please. :p
I'm not the author of Yata, I just wanted to help people posting in this thread having the problem that their addon was not skinned on startup.
And since you keep your opinion this is the only thing I can offer them... and no I'm not gonna fix all addons that have problems, I'm lazy as well ;)
Just write a plugin for Yata if you want fix it, its not a librarys job to make sure addons implement it correctly.. its the addons job to make sure of that.
LibButtonFacade was created so that authors could control how their addons get skinned, they didn't have to go in and submit patches or touch the code of the skinning addon, nor did the author of the skinning addon have to keep up-to-date on every addon with buttons or when code changed in those addons, and also so that users didn't have to have useless code for 20 different addons when all they used was one.
ButtonFacade really is *better* than cyCircled, for those reasons. And the authors agreed (at least most did), which is why they switched. It isn't ButtonFacade's place to fix bugs with other addons in its code.
<-- Post 1000. Epic. Right? IT DON'T MATTER! ;p
There are many addons that support ButtonFacade on "non action button objects". Tuller is wrong.
And the beauty of the system as it exists now is that BF support doesn't even need to be in the addon itself. If Yata isn't being maintained by its author and nobody else is willing to step up and add BF support (anyone can commit to its WowAce SVN repository), just write a third-party plugin. Look at ButtonFacade_ItemRack for an example.
In that case, the bug fixes are usually added to the graphics drivers because the applications are adhering to the published standard, and the graphics drivers have bugs in their standards support. The correct solution is indeed for the graphics driver to be updated with the fixes. Asking application developers to be aware of and account for every bug in every graphics driver every user might be using ever is simply ridiculous.
Also, if you don't want to download updates that don't apply to you, read the changelog before you download.
Most people probably do not use different skins, but rather different settings for the same skin on different addons. For example, due to the way Satrina Buff Frames handles debuff highlighting, I need to set the skin's highlight color to 0% opacity in order for things to look right... but I do not want invisible highlights on my other addons.
Generally speaking, you're seeing a problem where there is no problem. The settings that are displayed on the main/global panel have nothing to do with any addon. If an addon isn't saving its skin settings correctly, that is not an issue with ButtonFacade, and would not be resolved by ButtonFacade showing something different on the global settings panel. The only thing ButtonFacade could do would be to force all addons to reapply their individual settings... which still would not help if the addon isn't saving its settings. Your "solution" is the equivalent of opening the config window and using the global panel to bulldoze all existing settings and overwrite them with your new choices. Adding this behavior to ButtonFacade would be a horrible thing for most users, as it would essentially destroy the system's ability to skin different addons and different parts of addons differently. It only solves your "problem" because you're using an addon that doesn't support the established API correctly. The correct solution would be to fix that addon, not ask for new behavior in ButtonFacade that would totally break the system.
It loads without errors, however buff & debuff icons are not skinned, while temporary enchants still work properly. Drilling down to the individual group settings in the BF options seems to indicate it's still set to the Caith skin I usually use, so would appear that it's not properly applying the settings on load. Changing anything in the FacadeBuffs section in the BF options or the individual groups below does not seem to affect it, however changing the global BF options does... and it continues working fine until next login.
I am adapting my mod to use ButtonFacade and so far it's been pretty easy. My issue is that my groups don't show up in the Button Facade config. I only have a heading for the mod itself.
The groups appear to be working properly, my skin callback gets called for each one, and the settings are being saved and restored properly. I just don't have the option of configuring them individually.
Here are some code snippets:
local LBF = LibStub("LibButtonFacade")
-- in initialize function
-- buttonfacade callback
if LBF then
LBF:RegisterSkinCallback('ButtonTimers', ABT:OnSkin(), self)
end
end
-- Button Facade Callback
function ABT:OnSkin(skin, gloss, backdrop, group, button, colors)
if group then
ABT.db.char["buttonFacade"..group] = {skin, gloss, backdrop, colors}
end
end
-- creating buttons
if LBF then
LBF:Group('ButtonTimers', group):AddButton(button)
end
end
if LBF then
local bfOptions = ABT.db.char["buttonFacade"..group]
if bfOptions then
LBF:Group('ButtonTimers', group):Skin (unpack(bfOptions))
end
end
You're actually calling the function ABT:OnSkin() when that line is run, and registering its return value (if any) to the callback. I'm assuming you want to register the function itself to the callback, in which case you should be doing this:
(I'm also assuming that "self" and "ABT" are the same thing in that line's scope, so using one or the other exclusively is more consistent and readable.)
That's odd, the OnSkin function is being called when I modify the skin. I wonder how it's working?