@JJ: So, "Border" is now "Normal"? (Makes sense). Also, are the default numbers you put in the sample skin the numbers for the rebuilt Blizzard buttons or were they just plugged in?
And can you swap the last two arguments in the AddSkin function and make the default for overwrite=true so that it can be left out when just adding a skin? Ex:
ButtonFacade:AddSkin(SkinName, SkinData)
@Nev: It's good do see posting in here. Does this mean we'll see ButtonFacade support in BT3 (or 4)? :D
@JJ: So, "Border" is now "Normal"? (Makes sense). Also, are the default numbers you put in the sample skin the numbers for the rebuilt Blizzard buttons or were they just plugged in?
The sample skin is essentially how ButtonFacade rebuilds the Blizzard default style. So, those numbers are directly from that style.
And can you swap the last two arguments in the AddSkin function and make the default for overwrite=true so that it can be left out when just adding a skin? Ex:
ButtonFacade:AddSkin(SkinName, SkinData)
Will do.
@StormFX: Also, not sure if it was corrected in my last PM to you, but if you have an Active layer listed, it should be renamed to Checked.
I think I'd approch adding buttons/groups abit differently, instead of being oriented around a group I would orientate it more around the button. (Its just how I'd approch it, not sure if its a better way or not)
local buttons = {}
local addons = {}
local groups = {}
function lib:AddButton("addonName", {button}, {buttonData} or nil)
buttons[button] = buttonData
addons[button] = addonName
end
function lib:RemoveButton({button}, noReskin or nil)
addons[button] = nil
groups[button] = nil
buttons[button] = nil
end
function lib:SetGroup({button}, "groupName" or nil)
groups[button] = groupName
end
function lib:GetButtonInfo({button})
return buttons[button], addons[button], groups[button]
end
function lib:ListButtons()
local button, buttonData = next(buttons)
while button ~= nil do
return function()
return button, buttonData, addons[button], groups[button]
end
button, buttonData = next(buttons, button)
end
end
function lib:ListAddonButtons(addon)
local button, buttonAddon = next(addons)
while button ~= nil do
if buttonAddon == addon then
return function()
return button, buttons[button], groups[button]
end
end
button, buttonAddon = next(addons, button)
end
end
function lib:ListGroupButtons(group)
local button, buttonGroup = next(groups)
while button ~= nil do
if buttonGroup == group then
return function()
return button, buttons[button], addons[button]
end
end
button, buttonGroup = next(groups, button)
end
end
do
local t = {}
function lib:ListAddons()
for k in pairs(t) do t[k] = nil end
for _,_,addon in lib:ListButtons()
if not t[addon] then t[addon] = true end
end
return pairs(t)
end
end
do
local t = {}
function lib:ListGroups()
for k in pairs(t) do t[k] = nil end
for _,_,_,group in lib:ListButtons()
if not t[group] then t[group] = true end
end
return pairs(t)
end
end
-- group > addon > default
local defaultSkin = "Blizzard"
local addonSkins = {
--["AddonExample"] = "Dreamlayout"
}
local groupSkins = {
--["GroupExample"] = "Zoomed"
}
function lib:ApplyGroupSkin(group)
local groupSkin = groupSkins[group]
for button in lib:ListGroupButtons(group) do
lib:ApplyButtonSkin(button, groupSkin)
end
end
function lib:ApplyAddonSkin(addon)
local addonSkin = addonSkins[addon]
for button, _, group in lib:ListAddonButtons(addon) do
if not groupSkins[group] then
lib:ApplyButtonSkin(button, addonSkin)
end
end
end
function lib:ApplyDefaultSkin()
for button, _, addon, group in lib:ListButtons() do
if not addonSkins[addon] or not groupSkins[group] then
lib:ApplyButtonSkin(button, defaultSkin)
end
end
end
function lib:ApplyAllSkins()
for button, _, addon, group in lib:ListButtons() do
local skin = addonSkins[addon] or groupSkins[group] or defaultSkin
lib:ApplyButtonSkin(button, skin)
end
end
I think I'd approch adding buttons/groups abit differently, instead of being oriented around a group I would orientate it more around the button. (Its just how I'd approch it, not sure if its a better way or not)
The difficulty with your technique (which is what I originally attempted) is in getting access to and setting the skin of an entire group for GUI purposes. It makes it particularly difficult. The technique I'm using makes things easy. Just create a group and add buttons to that group. If you want certain buttons in a group to be different from the norm, you simply add them to a sub-group (Addon,Group,Button). The code to handle things is also clearer to read and, I believe, just as, if not more, efficient.
@StormFX: Also, not sure if it was corrected in my last PM to you, but if you have an Active layer listed, it should be renamed to Checked.
I have "Checked" in mine. Also, is "Border" now "Normal"? You mentioned something about it and want to be sure.
P.S. Does the current SVN version of IB support this new stuff so I can test it out and try converting a skin?
P.P.S. When the code checks for a "gloss" texture, if there is one, can it verify that the texture exists and make the "gloss" optional per skin (if it doesn't already). This saves skin authors from creating multiple skins for a small variance.
I managed to get my button to work properly, with one problem.
Can we extend the button-data API so i can supply references to different Pushed/Checked/Highlight/Normal textures?
I have all the "normal" art on a different frame now, and use the special textures of the secure frame, but it does not Skin those because it trys to access the artwork-only frame, which doesnt have them.
I have "Checked" in mine. Also, is "Border" now "Normal"? You mentioned something about it and want to be sure.
Yes, the old Border layer is now the Normal layer. But there is a new layer, Border, which Blizzard uses to signal when an Item is equipped.
P.S. Does the current SVN version of IB support this new stuff so I can test it out and try converting a skin?
Yes. I have some additions to make tonight, and the ButtonFacade GUI can easily be opened with /bf. I will also post some lua code tonight that creates and allows you to test a skinned button. I will probably also start adding Facade support to InfiniBar-2.0 tonight, so creating and converting skins should be a bit easier.
P.P.S. When the code checks for a "gloss" texture, if there is one, can it verify that the texture exists and make the "gloss" optional per skin (if it doesn't already). This saves skin authors from creating multiple skins for a small variance.
If either the skin or the button indicates no Backdrop or Gloss layer, the button will not make use of that layer. So, enabling Gloss on a skin that doesn't support it will not show any gloss layer. Likewise, if the gloss is disabled when using the LBFGroup:Skin() function, the gloss will not be used, even when specified by the skin. The same behavior occurs for Backdrops.
Also note, that if a layer cannot be found (or if the btndata table supplies it as false), LBF will not skin that layer. Layers that are not named in the same pattern that Blizzard uses must be supplied in the btndata table.
Quote from Nevcairiel »
I managed to get my button to work properly, with one problem.
Can we extend the button-data API so i can supply references to different Pushed/Checked/Highlight/Normal textures?
I have all the "normal" art on a different frame now, and use the special textures of the secure frame, but it does not Skin those because it trys to access the artwork-only frame, which doesnt have them.
That would really be appreciated :)
Yes. I'll look into it tonight and make sure this works correctly.
Yes. I'll look into it tonight and make sure this works correctly.
I have added checks to see if the Normal, Pushed, etc. textures are speicifed in btndata. If so, they will be used instead of the standard choices. This is as of Revision 11.
Also as of Revision 11, the ability to Set skin settings on all registered buttons, in all addons, is in.
I'll be adding Facade support to InfiniBar-2.0 later tonight. After that I will add module and FuBar profile support to ButtonFacade, and will then transfer ButtonFacade over to the WoWAce SVN.
I'll be adding Facade support to InfiniBar-2.0 later tonight. After that I will add module and FuBar profile support to ButtonFacade, and will then transfer ButtonFacade over to the WoWAce SVN.
Revision 12 fixes some bugs still in the Library and the GUI. Adding support to InfiniBar-2.0 helped me find them. :)
I'm going to go eat dinner, then I'll tackle the module support and FuBar stuff.
Yes, the old Border layer is now the Normal layer. But there is a new layer, Border, which Blizzard uses to signal when an Item is equipped.
I see. So now the layer the button's border texture on is called "Normal" and the equip layer is called "Border"? I want to make sure the template is right. >.<
If either the skin or the button indicates no Backdrop or Gloss layer, the button will not make use of that layer. So, enabling Gloss on a skin that doesn't support it will not show any gloss layer. Likewise, if the gloss is disabled when using the LBFGroup:Skin() function, the gloss will not be used, even when specified by the skin. The same behavior occurs for Backdrops.
Also note, that if a layer cannot be found (or if the btndata table supplies it as false), LBF will not skin that layer. Layers that are not named in the same pattern that Blizzard uses must be supplied in the btndata table.
Actually, what I meant is that when a skin has a "gloss" enabled, the user needs to have the option to disable the gloss for that skin to prevent us from having to make a second skin with the "gloss" layer disabled.
P.S. Sorry for the random jumps in train-of-thought. That's how I roll. If something comes to me, I gotta get it in written form or I forgot. Age FTL.
I see. So now the layer the button's border texture on is called "Normal" and the equip layer is called "Border"? I want to make sure the template is right. >.<
Exactly.
Actually, what I meant is that when a skin has a "gloss" enabled, the user needs to have the option to disable the gloss for that skin to prevent us from having to make a second skin with the "gloss" layer disabled.
That's exactly what I mean. The Skin, the Gloss, and the Backdrop are the three options players have. So don't make identical skins without gloss and backdrop.
P.S. Sorry for the random jumps in train-of-thought. That's how I roll. If something comes to me, I gotta get it in written form or I forgot. Age FTL.
Attached is my "template" file. Please feel free to make adjustments/tweaks. Especially to the updated Border/Normal layers and if the order's been changed at all. You can add to the g-code if you want, as well. When it gets on the SVN, I can update it more frequently.
Attached is my "template" file. Please feel free to make adjustments/tweaks. Especially to the updated Border/Normal layers and if the order's been changed at all. You can add to the g-code if you want, as well. When it gets on the SVN, I can update it more frequently.
Looks good. I changed the way you were accessing the Library to the proper method, but changed nothing else.
Last thing I need to do before transferring to the Ace SVN is create a simple Hide Blizzard Frames module and get it working correctly. This just to demonstrate how modules are to be created.
Ok. You might want to tweak that "Border" layer element. I just copied the attributes from the "Normal" texture and renamed it.
Throwing the following error with an "external" (separate) skin when selecting it in the GUI:
ButtonFacade\LibButtonFacade\LibButtonFacade.lua:165: attempt to index local 'skinlayer' (a nil value)
Also, can you adjust it so the drop-down displays the currently active skin and "sticks" when you select a new skin?
As I was trying to convert a test skin, I noticed something: cyCircled uses the default "Normal" texture for all skins. From what I can tell, the "Normal" texture is just a transparent overlay for the skill icon that changes to the "Pushed"/"Disabled" texture during their respective states. (IE the "Pushed" texture is a semi-transparent, bluish circle and the "Disabled" texture is a semi-transparent black/gray overlay.) So using this for the "base" texture of the skin isn't really viable because the skin author would have to replace both of those state textures (most skins actually use them).
Or am I missing something? I tried to verify it, but it won't load my external skin. I know that cyCircled actually creates a new layer above the icon called "Overlay" that contains the skins base texture then utilizes the various states to enhance that layer for those states.
Okay, I have transferred ButtonFacade to the WowAce SVN. I'd like to get more than the three skins added to it, and would love any submissions for modules. I think it definitely needs an improvement to (or elimination of) the Blizzard Main bar hider module. It also needs modules to properly skin and take control of the Blizzard buttons. Unless someone else gets to that, I'll write it up soon enough.
Actionbar Addon authors are welcome to take a look at my InfiniBar-2.0 code to see how I am creating groups and adding buttons to them. If anything is unclear, let me know and I will help you out. I'm on IRC quite often, so if you see me there and need assistance, just ask.
The DreamLayout and Zoomed skins have been moved to their own files in a Skins folder, which will help skinners to see how a working skin is created. Textures for skins should be placed within the Textures directory, and accessed with [[Interface\AddOns\ButtonFacade\Textures\<filename>]]. This special construct (using [[ and ]]) allows you to use \ instead of \\ as your directory separator.
Although I do consider ButtonFacade to be "my" addon, I appreciate any submissions, bug-fixes, new modules, etc. New skins can be added, but I don't want to go too crazy. Much more than ten or so additional skins, and I think we should create a skin package for additional related skins. Most important to keep in mind when committing to ButtonFacade is "you break it, you fix it". Unless, of course, someone else fixes it for you. :)
Okay, I have transferred ButtonFacade to the WowAce SVN.
Wewt! Updating from G-Code is a PITA! :)
I'd like to get more than the three skins added to it
New skins can be added, but I don't want to go too crazy. Much more than ten or so additional skins, and I think we should create a skin package for additional related skins.
I strongly recommend against this. cyCircled started off that way and ended up being a > 5mb download every update. It's silly to include additional skins that some most people won't even be using. Especially those will large texture files. By having additional skins as external packages, it reduces SVN bandwidth and makes updating less of a chore.
Although I do consider ButtonFacade to be "my" addon, I appreciate any submissions, bug-fixes, new modules, etc. Most important to keep in mind when committing to ButtonFacade is "you break it, you fix it".
Forewarning: I'm a stickler for grammar/accuracy (usually), so if it's OK, I may tweak the "Template" a bit as I play with the skins.
Alright, started configuring Onyx and noticed some things. First, when an item is equipped, it's using the "Checked" texture. Secondly, the "Pushed" doesn't seem to be working (Added a texture, dimensions, etc). Finally, the "Flash" element is missing from the "template". I'll fix this later, but wanted you to know. :)
I strongly recommend against this. cyCircled started off that way and ended up being a > 5mb download every update. It's silly to include additional skins that some most people won't even be using. Especially those will large texture files. By having additional skins as external packages, it reduces SVN bandwidth and makes updating less of a chore.
Yeah. I would like to get a circular skin such as Serenity added though.
Forewarning: I'm a stickler for grammar/accuracy (usually), so if it's OK, I may tweak the "Template" a bit as I play with the skins.
Don't mind at all, as long as the template is always capable of being functional (despite not being referenced even indirectly by the TOC file). New skinners should always be able to open that file, copy it to a new file, change the right settings and have it work.
Quote from StormFX »
Alright, started configuring Onyx and noticed some things. First, when an item is equipped, it's using the "Checked" texture. Secondly, the "Pushed" doesn't seem to be working (Added a texture, dimensions, etc). Finally, the "Flash" element is missing from the "template". I'll fix this later, but wanted you to know. :)
If you're talking about InfiniBar, then yes IB2 does have issues with this stuff. I need to get this sort of stuff working. It's a result of my use of a non-secure button proxy.
Quote from Seerah »
Should the subject of this thread be updated with the correct name now that it's on the svn?
First post has been updated, as has this post. I'm too lazy to go back and edit the rest. :p
Besides, once I get this closer to release, I'll get this thread closed and start an official thread in General Addons.
Questions:
Thoughts on where extraneous modules should go? I'm thinking if it's a simple and integral module it should be in ButtonFacade, but if it's a more complex, or possibly less often used module (such as a module that adds support for a button addon) that it should get it's own folder under /trunk.
As it currently stands, the Template, and the built-in skin files silently fail if LibButtonFacade is not found. I'm wondering if this shouldn't throw a custom error with info on how to correct the problem. In addition a skin package could add ButtonFacade as an Optional Dependency, and would then throw out the error that the user needs to install ButtonFacade for the skin to work. Opinions?
Modules that add support for addons should follow the format BarAddon_ButtonFacade, to distinguish them from skin packs which should follow the format ButtonFacade_SkinName.
With regard to skins included in ButtonFacade, I'd limit it to Blizzard, Zoomed, and Dreamlayout skins. Keep skins that require additional graphics in their own packs, not only to keep the download size small, but because tastes vary; personally I can't stand any of cyCircled's included skins, so it's somewhat irritating when I have to redownload all of those files every time there's a minor tweak or localization update. Plus, many users are perfectly happy with the Blizzard look, so there's no need to shove 2MB of texture files at them that they'll never use. Those three (Blizz, zoom, dream) skins could even be included in the lib itself, since they do not require any non-Blizzard-provided textures.
I'm not sure what "the Template" and "the built-in skin files" failing or erroring is all about; I thought the whole purpose behind you writing this as a lib was so that bar addons wanting to support this system could embed the lib and not bother the aforementioned users who are happy with the Blizz look. If users are downloading a ButtonFacade_ExtraSkin package, but have no compatible addons, then yes, it should error. Other than that... I'm tired, and maybe I'm missing something here. :P
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
And can you swap the last two arguments in the AddSkin function and make the default for overwrite=true so that it can be left out when just adding a skin? Ex:
@Nev: It's good do see posting in here. Does this mean we'll see ButtonFacade support in BT3 (or 4)? :D
The sample skin is essentially how ButtonFacade rebuilds the Blizzard default style. So, those numbers are directly from that style.
Will do.
@StormFX: Also, not sure if it was corrected in my last PM to you, but if you have an Active layer listed, it should be renamed to Checked.
The difficulty with your technique (which is what I originally attempted) is in getting access to and setting the skin of an entire group for GUI purposes. It makes it particularly difficult. The technique I'm using makes things easy. Just create a group and add buttons to that group. If you want certain buttons in a group to be different from the norm, you simply add them to a sub-group (Addon,Group,Button). The code to handle things is also clearer to read and, I believe, just as, if not more, efficient.
I have "Checked" in mine. Also, is "Border" now "Normal"? You mentioned something about it and want to be sure.
P.S. Does the current SVN version of IB support this new stuff so I can test it out and try converting a skin?
P.P.S. When the code checks for a "gloss" texture, if there is one, can it verify that the texture exists and make the "gloss" optional per skin (if it doesn't already). This saves skin authors from creating multiple skins for a small variance.
Can we extend the button-data API so i can supply references to different Pushed/Checked/Highlight/Normal textures?
I have all the "normal" art on a different frame now, and use the special textures of the secure frame, but it does not Skin those because it trys to access the artwork-only frame, which doesnt have them.
That would really be appreciated :)
Yes, the old Border layer is now the Normal layer. But there is a new layer, Border, which Blizzard uses to signal when an Item is equipped.
Yes. I have some additions to make tonight, and the ButtonFacade GUI can easily be opened with /bf. I will also post some lua code tonight that creates and allows you to test a skinned button. I will probably also start adding Facade support to InfiniBar-2.0 tonight, so creating and converting skins should be a bit easier.
If either the skin or the button indicates no Backdrop or Gloss layer, the button will not make use of that layer. So, enabling Gloss on a skin that doesn't support it will not show any gloss layer. Likewise, if the gloss is disabled when using the LBFGroup:Skin() function, the gloss will not be used, even when specified by the skin. The same behavior occurs for Backdrops.
Also note, that if a layer cannot be found (or if the btndata table supplies it as false), LBF will not skin that layer. Layers that are not named in the same pattern that Blizzard uses must be supplied in the btndata table.
Yes. I'll look into it tonight and make sure this works correctly.
I have added checks to see if the Normal, Pushed, etc. textures are speicifed in btndata. If so, they will be used instead of the standard choices. This is as of Revision 11.
Also as of Revision 11, the ability to Set skin settings on all registered buttons, in all addons, is in.
I'll be adding Facade support to InfiniBar-2.0 later tonight. After that I will add module and FuBar profile support to ButtonFacade, and will then transfer ButtonFacade over to the WoWAce SVN.
Revision 12 fixes some bugs still in the Library and the GUI. Adding support to InfiniBar-2.0 helped me find them. :)
I'm going to go eat dinner, then I'll tackle the module support and FuBar stuff.
I see. So now the layer the button's border texture on is called "Normal" and the equip layer is called "Border"? I want to make sure the template is right. >.<
Actually, what I meant is that when a skin has a "gloss" enabled, the user needs to have the option to disable the gloss for that skin to prevent us from having to make a second skin with the "gloss" layer disabled.
P.S. Sorry for the random jumps in train-of-thought. That's how I roll. If something comes to me, I gotta get it in written form or I forgot. Age FTL.
Exactly.
That's exactly what I mean. The Skin, the Gloss, and the Backdrop are the three options players have. So don't make identical skins without gloss and backdrop.
No Problem. :)
Attached is my "template" file. Please feel free to make adjustments/tweaks. Especially to the updated Border/Normal layers and if the order's been changed at all. You can add to the g-code if you want, as well. When it gets on the SVN, I can update it more frequently.
Looks good. I changed the way you were accessing the Library to the proper method, but changed nothing else.
Last thing I need to do before transferring to the Ace SVN is create a simple Hide Blizzard Frames module and get it working correctly. This just to demonstrate how modules are to be created.
Throwing the following error with an "external" (separate) skin when selecting it in the GUI:
Also, can you adjust it so the drop-down displays the currently active skin and "sticks" when you select a new skin?
As I was trying to convert a test skin, I noticed something: cyCircled uses the default "Normal" texture for all skins. From what I can tell, the "Normal" texture is just a transparent overlay for the skill icon that changes to the "Pushed"/"Disabled" texture during their respective states. (IE the "Pushed" texture is a semi-transparent, bluish circle and the "Disabled" texture is a semi-transparent black/gray overlay.) So using this for the "base" texture of the skin isn't really viable because the skin author would have to replace both of those state textures (most skins actually use them).
Or am I missing something? I tried to verify it, but it won't load my external skin. I know that cyCircled actually creates a new layer above the icon called "Overlay" that contains the skins base texture then utilizes the various states to enhance that layer for those states.
Actionbar Addon authors are welcome to take a look at my InfiniBar-2.0 code to see how I am creating groups and adding buttons to them. If anything is unclear, let me know and I will help you out. I'm on IRC quite often, so if you see me there and need assistance, just ask.
The DreamLayout and Zoomed skins have been moved to their own files in a Skins folder, which will help skinners to see how a working skin is created. Textures for skins should be placed within the Textures directory, and accessed with [[Interface\AddOns\ButtonFacade\Textures\<filename>]]. This special construct (using [[ and ]]) allows you to use \ instead of \\ as your directory separator.
Although I do consider ButtonFacade to be "my" addon, I appreciate any submissions, bug-fixes, new modules, etc. New skins can be added, but I don't want to go too crazy. Much more than ten or so additional skins, and I think we should create a skin package for additional related skins. Most important to keep in mind when committing to ButtonFacade is "you break it, you fix it". Unless, of course, someone else fixes it for you. :)
Wewt! Updating from G-Code is a PITA! :)
I strongly recommend against this. cyCircled started off that way and ended up being a > 5mb download every update. It's silly to include additional skins that some most people won't even be using. Especially those will large texture files. By having additional skins as external packages, it reduces SVN bandwidth and makes updating less of a chore.
Forewarning: I'm a stickler for grammar/accuracy (usually), so if it's OK, I may tweak the "Template" a bit as I play with the skins.
Yeah. I would like to get a circular skin such as Serenity added though.
Don't mind at all, as long as the template is always capable of being functional (despite not being referenced even indirectly by the TOC file). New skinners should always be able to open that file, copy it to a new file, change the right settings and have it work.
If you're talking about InfiniBar, then yes IB2 does have issues with this stuff. I need to get this sort of stuff working. It's a result of my use of a non-secure button proxy.
First post has been updated, as has this post. I'm too lazy to go back and edit the rest. :p
Besides, once I get this closer to release, I'll get this thread closed and start an official thread in General Addons.
Questions:
Thoughts on where extraneous modules should go? I'm thinking if it's a simple and integral module it should be in ButtonFacade, but if it's a more complex, or possibly less often used module (such as a module that adds support for a button addon) that it should get it's own folder under /trunk.
As it currently stands, the Template, and the built-in skin files silently fail if LibButtonFacade is not found. I'm wondering if this shouldn't throw a custom error with info on how to correct the problem. In addition a skin package could add ButtonFacade as an Optional Dependency, and would then throw out the error that the user needs to install ButtonFacade for the skin to work. Opinions?
With regard to skins included in ButtonFacade, I'd limit it to Blizzard, Zoomed, and Dreamlayout skins. Keep skins that require additional graphics in their own packs, not only to keep the download size small, but because tastes vary; personally I can't stand any of cyCircled's included skins, so it's somewhat irritating when I have to redownload all of those files every time there's a minor tweak or localization update. Plus, many users are perfectly happy with the Blizzard look, so there's no need to shove 2MB of texture files at them that they'll never use. Those three (Blizz, zoom, dream) skins could even be included in the lib itself, since they do not require any non-Blizzard-provided textures.
I'm not sure what "the Template" and "the built-in skin files" failing or erroring is all about; I thought the whole purpose behind you writing this as a lib was so that bar addons wanting to support this system could embed the lib and not bother the aforementioned users who are happy with the Blizz look. If users are downloading a ButtonFacade_ExtraSkin package, but have no compatible addons, then yes, it should error. Other than that... I'm tired, and maybe I'm missing something here. :P