Authors CurseForge

Quote from StormFX »

@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

Quote from Sorata »

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.

Quote from StormFX »

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.

Quote from jjsheets »

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.

Quote from jjsheets »

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.

Quote from StormFX »

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.

No Problem. :)

Quote from StormFX »

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.

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. :)

Quote from StormFX »

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