ButtonFacade presents users with hierarchical skin settings. So for example for a Bar mod there can be skin settings at the Mod / Bar / Button level. Now to implement this I think you would need a way to null out a setting at a certain level. It's buttons then get dropped from its skin and added to the skin 1 level higher up.
So can we have a special "skin" that does this nulling in the skin list? Something like "none" or "Use Parent Skin" or something with some special value indicating to remove the skin info ("nil" or something). Selecting this skin just nulls out skin info at its level (so on a button or bar or the mod) so that the higher up setting can be used. Defaults to Blizzard if nothing is specified anywhere of course.
Or am I missing something and needlessly fighting the system?
Groups store their skin info separate from each other, including the parent. It never was intended to use the parent group's skin settings as a default. When setting a parent group's settings, the parent group overwrites all subgroups. I do like the idea of being able to directly copy a parent's skin settings, so it'll probably be added soon.
...I do like the idea of being able to directly copy a parent's skin settings, so it'll probably be added soon.
Not quite sure what that means & rereading my post I realize it was not clear. So in AutoBar for example, I plan on supporting the hierarchical settings as described. The way it would work is as follows for the Mod, BarA, BarB, ButtonA1, ButtonA2:
1) At first all have no setting so default Blizzard skin is used.
2) User selects Caith for the mod. AutoBar thus adds all buttons not to their Bar, but to the mods group, so everything is skinned with Caith. Only AutoBar is registered so that is all that is skinnable from ButtonFacade UI. I suppose I could also register both BarA and BarB but have no buttons in them. If a user then selects a skin for them in the BF UI I can add buttons to them after the callback to save the skin.
3) Next the User sets the skin on BarA to be DreamLayout. AutoBar thus removes all its buttons from the current (AutoBar) group, creates the BarA group, and skins it with DreamLayout. Everything else still uses Caith.
4) User (through the AutoBar UI), sets ButtonA2 to Gears: Spark. ButtonA2 now shows up in BF UI as it is removed from BarA button list.
5) User decides to ditch DreamLayout.
Ok, this is where the requested feature of having a way to select a nil skin comes in.
User chooses "Use Parent Skin" or whatever it is called as the skin for BarA.
AutoBar sees the special value chosen for skin and thus deletes the group for BarA, and adds its buttons to the AutoBar (parent) group. Everything is back to Caith except for ButtonA2 which remains Gears: Spark.
Note: The current BF implemetation does not change at all except for a special "nil out this skin" value being added to the list used by LBF:ListSkins().
I can just hack in this value or clone the list then hack it in, but it would be better to have a common way of doing this...
Not quite sure what that means & rereading my post I realize it was not clear. So in AutoBar for example, I plan on supporting the hierarchical settings as described. The way it would work is as follows for the Mod, BarA, BarB, ButtonA1, ButtonA2:
The problem with doing it that way is that it would make the ButtonFacade UI inconsistent. It would require people to hunt down the settings in the AutoBar GUI, and I guarantee people would be crying when they can't skin BarA in BF because you've moved all of its buttons into the addon group and removed it from BF.
But... like I said, the ability to replicate the settings of the next group up, "Use Parent Settings", is a good idea, will be implemented soon, keeps the UI consistent, and gives all of the control to the users.
The problem with doing it that way is that it would make the ButtonFacade UI inconsistent. It would require people to hunt down the settings in the AutoBar GUI, and I guarantee people would be crying when they can't skin BarA in BF because you've moved all of its buttons into the addon group and removed it from BF.
But... like I said, the ability to replicate the settings of the next group up, "Use Parent Settings", is a good idea, will be implemented soon, keeps the UI consistent, and gives all of the control to the users.
Excellent. Sounds like "Use Parent Settings" would solve all the issues.
[2008/05/14 21:14:41-3487-x1]: AceConfigDialog-3.0\AceConfigDialog-3.0.lua:1452: AceConfigRegistry-3.0:ValidateOptionsTable(): Poppins.args.modules.args.ButtonFacadeSkins.args.skins.args[Entropy: Gold] - key name contained spaces (or control characters)
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:46: in function <...-3.0\AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:41>
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:165: in function <...-3.0\AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:159>
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:217: in function <...-3.0\AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:183>
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:218: in function <...-3.0\AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:183>
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:218: in function <...-3.0\AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:183>
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:218: in function <...-3.0\AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:183>
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:249: in function `ValidateOptionsTable'
AceConfigRegistry-3.0\AceConfigRegistry-3.0.lua:295: in function `app'
AceConfigDialog-3.0\AceConfigDialog-3.0.lua:1452: in function `Open'
Poppins-1.0\Poppins.lua:211: in function `?'
Interface\FrameXML\ChatFrame.lua:3003: in function `ChatEdit_ParseText':
Interface\FrameXML\ChatFrame.lua:2732: in function `ChatEdit_SendText':
Interface\FrameXML\ChatFrame.lua:2753: in function `ChatEdit_OnEnterPressed':
<string>:"*:OnEnterPressed":1: in function <[string "*:OnEnterPressed"]:1>
---
Looks like Poppins in mishandling the string key names.
JJ: I did some tweaking on the (included) skins to make sure everything lined up correctly (especially Autocast). This required me to remove the Template attribute and adjust the Zoomed skin separately. I also added color selection support for those skins. :)
is the skin from the Cycircled_Vol allready ported? Is anyone willing to take up that job? I kinda like the Vol buttons.
thanks!
The "Vol" name space is reserved for Zeal (the original creator of Vol). My port over (of Vol) is called "Apathy". Check the skin thread for a list of all skins with links.
I don't know if what I'm asking is strictly speaking in ButtonFacade scope but I seem to remember that, in Blizzard's default UI, when a cooldown has ended there is a small "twinkling" animation flashing. Would it be something that could be added to BF ?
I don't know enough about the button bars arcana so it's perfectly plausible that would it be something which would be more appropriate in the scope of a button bar add-on.
Installed Button Facade for the first time last night, using r73869. Glad to finally have an alternative to cyCircled.
Have a display issue in the options menu. When I opened up /bf and selected Elements the skin setting was blank, gloss was at 0%, and the backdrop check box is checked, but greyed out. I chose the Apathy skin, set my gloss to 25%. I then clicked through each Addon Specific setup (Using Bongos 3, Cooldown Buttons, Satrina Buff Frames). Each of them was recording the Apathy and Gloss slection - backdrop was not checked. I then went through each subsection within the addons to check backdrop for each.
Now here is the issue. When I /rl, all of my selections remain the same on screen. Buttons are still displaying as Apathy with 25% gloss, and Backdrops are still displayed. However, opening /bf again, the Elements tab shows the skin setting is shown as blank, gloss is shown as 0%, and backdrop is checked but greyed out. Under each individual Addon they are displaying their Skin as Blizzard, Gloss at 0%, backdrop not checked. Again, my settings did not reset on /rl, they are still displaying as they did prior to the reload. The options menu simply isn't staying updated to reflect my actual settings.
I deleted my saved variables and started fresh again and the issue persists. This isn't a huge deal since it's just a display error and the settings are actually being maintained between sessions and this being a 'Set it up once and forget it' type setup. Opening /bf and seeing settings as their default is a little confusing though.
Unfortunately there's no error for me to report. Hope that helps you track this down to fix it.
I don't know if what I'm asking is strictly speaking in ButtonFacade scope but I seem to remember that, in Blizzard's default UI, when a cooldown has ended there is a small "twinkling" animation flashing. Would it be something that could be added to BF ?
I don't know enough about the button bars arcana so it's perfectly plausible that would it be something which would be more appropriate in the scope of a button bar add-on.
Cooldowns are something that are the responsibility of the bar mod addon author. The cooldown "star flash" or "twinkle" is part of the of the spiral object, however, depending on how an addon is coded to handle cooldowns, the cooldown spiral can be hidden too early to show the "star flash".
So what I am saying, is that the "star flash" is always there, just some addons either intentionally or unintentionally hide the effect.
when a cooldown has ended there is a small "twinkling" animation flashing. Would it be something that could be added to BF?
Not sure where that particular element would apply, but most cool down mods have it (IE CoolDownCount)
Have a display issue in the options menu.
BF does not save the skin settings, the add-on does. Therefore, I don't know that there's a way for BF to see what each add-on currently has saved (each add-on's saved settings might be named differently), much less display it.
When skin color on a user level is finished is that going to be done through ButtonFacade or the bar addons themselves?
That's a good question. The problem with letting the add-on handle it is that it requires the author to actually implement it. Some might not want to.
Currently, ButtonFacade saves nothing in regards to the skin. The problem this poses is that when you go to change skins, BF doesn't display what's currently selected.
My recommendation is that those selections and options be saved into BF.
I have been trying to fine-tune things in my addon if a user decides to use BF, however I am running into a small bit of confusion with how the normal texture is handled.
if skinlayer.Static and btndata.Normal ~= false then
btnlayer = btndata.Normal or button:GetNormalTexture()
if btnlayer then
btnlayer:SetTexture("")
btnlayer:Hide()
button.__bf_nonormaltexture = true
end
btnlayer = baselayer[button] or button:CreateTexture()
baselayer[button] = btnlayer
else
btnlayer = btndata.Normal or button:GetNormalTexture()
if baselayer[button] then baselayer[button]:Hide() end
end
if not btnlayer then return end
if skinlayer.Hide or btndata.Normal == false then
btnlayer:SetTexture("")
btnlayer:Hide()
return
end
This section of code attempts to create a normal texture on the button even if one already exists, and hides the original. Well, that is not what I want, so I set "btndata.Normal = false" to force BF to use the normal texture the buttons already have, as seems to be the logic.
Yet, the last if/then in the quoted code block with "btndata.Normal == false" the existing normal texture is hidden anyhow and fails to skin the buttons.
There may be a reason for BF to create a new normal texture even if one exists, and I have not tried to see if that is the case, however in order for me to handle the normal texture in my addon, I need a means to direct BF to use the already existing texture. Right now, it seems I can't.
Changing the last quoted if/then to -
if skinlayer.Hide then
btnlayer:SetTexture("")
btnlayer:Hide()
return
end
lets everything work.
Trying to make my addon's buttons change their own reference to the originally created texture to the field __bf_normaltexture BF adds has had mixed results.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Groups store their skin info separate from each other, including the parent. It never was intended to use the parent group's skin settings as a default. When setting a parent group's settings, the parent group overwrites all subgroups. I do like the idea of being able to directly copy a parent's skin settings, so it'll probably be added soon.
Not quite sure what that means & rereading my post I realize it was not clear. So in AutoBar for example, I plan on supporting the hierarchical settings as described. The way it would work is as follows for the Mod, BarA, BarB, ButtonA1, ButtonA2:
1) At first all have no setting so default Blizzard skin is used.
2) User selects Caith for the mod. AutoBar thus adds all buttons not to their Bar, but to the mods group, so everything is skinned with Caith. Only AutoBar is registered so that is all that is skinnable from ButtonFacade UI. I suppose I could also register both BarA and BarB but have no buttons in them. If a user then selects a skin for them in the BF UI I can add buttons to them after the callback to save the skin.
3) Next the User sets the skin on BarA to be DreamLayout. AutoBar thus removes all its buttons from the current (AutoBar) group, creates the BarA group, and skins it with DreamLayout. Everything else still uses Caith.
4) User (through the AutoBar UI), sets ButtonA2 to Gears: Spark. ButtonA2 now shows up in BF UI as it is removed from BarA button list.
5) User decides to ditch DreamLayout.
Ok, this is where the requested feature of having a way to select a nil skin comes in.
User chooses "Use Parent Skin" or whatever it is called as the skin for BarA.
AutoBar sees the special value chosen for skin and thus deletes the group for BarA, and adds its buttons to the AutoBar (parent) group. Everything is back to Caith except for ButtonA2 which remains Gears: Spark.
Note: The current BF implemetation does not change at all except for a special "nil out this skin" value being added to the list used by LBF:ListSkins().
I can just hack in this value or clone the list then hack it in, but it would be better to have a common way of doing this...
The problem with doing it that way is that it would make the ButtonFacade UI inconsistent. It would require people to hunt down the settings in the AutoBar GUI, and I guarantee people would be crying when they can't skin BarA in BF because you've moved all of its buttons into the addon group and removed it from BF.
But... like I said, the ability to replicate the settings of the next group up, "Use Parent Settings", is a good idea, will be implemented soon, keeps the UI consistent, and gives all of the control to the users.
Excellent. Sounds like "Use Parent Settings" would solve all the issues.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLooks like Poppins in mishandling the string key names.
JJ: I did some tweaking on the (included) skins to make sure everything lined up correctly (especially Autocast). This required me to remove the Template attribute and adjust the Zoomed skin separately. I also added color selection support for those skins. :)
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse Premium;)
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorAha! But.. it doesn't seem to like saving changes after a UI reload!
thanks!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe "Vol" name space is reserved for Zeal (the original creator of Vol). My port over (of Vol) is called "Apathy". Check the skin thread for a list of all skins with links.
I don't know enough about the button bars arcana so it's perfectly plausible that would it be something which would be more appropriate in the scope of a button bar add-on.
Have a display issue in the options menu. When I opened up /bf and selected Elements the skin setting was blank, gloss was at 0%, and the backdrop check box is checked, but greyed out. I chose the Apathy skin, set my gloss to 25%. I then clicked through each Addon Specific setup (Using Bongos 3, Cooldown Buttons, Satrina Buff Frames). Each of them was recording the Apathy and Gloss slection - backdrop was not checked. I then went through each subsection within the addons to check backdrop for each.
Now here is the issue. When I /rl, all of my selections remain the same on screen. Buttons are still displaying as Apathy with 25% gloss, and Backdrops are still displayed. However, opening /bf again, the Elements tab shows the skin setting is shown as blank, gloss is shown as 0%, and backdrop is checked but greyed out. Under each individual Addon they are displaying their Skin as Blizzard, Gloss at 0%, backdrop not checked. Again, my settings did not reset on /rl, they are still displaying as they did prior to the reload. The options menu simply isn't staying updated to reflect my actual settings.
I deleted my saved variables and started fresh again and the issue persists. This isn't a huge deal since it's just a display error and the settings are actually being maintained between sessions and this being a 'Set it up once and forget it' type setup. Opening /bf and seeing settings as their default is a little confusing though.
Unfortunately there's no error for me to report. Hope that helps you track this down to fix it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCooldowns are something that are the responsibility of the bar mod addon author. The cooldown "star flash" or "twinkle" is part of the of the spiral object, however, depending on how an addon is coded to handle cooldowns, the cooldown spiral can be hidden too early to show the "star flash".
So what I am saying, is that the "star flash" is always there, just some addons either intentionally or unintentionally hide the effect.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot sure where that particular element would apply, but most cool down mods have it (IE CoolDownCount)
BF does not save the skin settings, the add-on does. Therefore, I don't know that there's a way for BF to see what each add-on currently has saved (each add-on's saved settings might be named differently), much less display it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's a good question. The problem with letting the add-on handle it is that it requires the author to actually implement it. Some might not want to.
Currently, ButtonFacade saves nothing in regards to the skin. The problem this poses is that when you go to change skins, BF doesn't display what's currently selected.
My recommendation is that those selections and options be saved into BF.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumif skinlayer.Static and btndata.Normal ~= false then btnlayer = btndata.Normal or button:GetNormalTexture() if btnlayer then btnlayer:SetTexture("") btnlayer:Hide() button.__bf_nonormaltexture = true end btnlayer = baselayer[button] or button:CreateTexture() baselayer[button] = btnlayer else btnlayer = btndata.Normal or button:GetNormalTexture() if baselayer[button] then baselayer[button]:Hide() end end if not btnlayer then return end if skinlayer.Hide or btndata.Normal == false then btnlayer:SetTexture("") btnlayer:Hide() return endThis section of code attempts to create a normal texture on the button even if one already exists, and hides the original. Well, that is not what I want, so I set "btndata.Normal = false" to force BF to use the normal texture the buttons already have, as seems to be the logic.
Yet, the last if/then in the quoted code block with "btndata.Normal == false" the existing normal texture is hidden anyhow and fails to skin the buttons.
There may be a reason for BF to create a new normal texture even if one exists, and I have not tried to see if that is the case, however in order for me to handle the normal texture in my addon, I need a means to direct BF to use the already existing texture. Right now, it seems I can't.
Changing the last quoted if/then to -
if skinlayer.Hide then btnlayer:SetTexture("") btnlayer:Hide() return endlets everything work.
Trying to make my addon's buttons change their own reference to the originally created texture to the field __bf_normaltexture BF adds has had mixed results.