• 0

    posted a message on Masque - Official Thread
    Quote from Seerah
    *sniff* I came up with the Facade part... :p


    If the old version was just "Facade" it would have been 800% better than "Button Facade". I think adding the "Button" part makes it .... bleh ;)

    However, I came here to post a small issue.

    With the old BF, I was able to "cleanup" what it would not do with the Blizzard skin, in particular when the empty button is shown, the alpha needs to be set to 50% (SetVertexColor(1,1,1,0.5)). After some fiddling I am unable to get Masque to let me set that alpha. The 100% alpha of "Interface\Buttons\UI-Quickslot" is a bit much. Any chance in your hook of SetNormalTexture() that if the default "Blizzard" skin is selected and the empty texture is set that it can also set the alpha to 50%? Then set the alpha of the normal texture back to 100% when "Interface\Buttons\UI-Quickslot2" is set?
    Posted in: General AddOns
  • 0

    posted a message on Masque - Official Thread
    First, thanks for adding :GetSkin() back, I am working with it now to see if it works as before with BF ;)

    I also wanted to comment on the name of the addon. 1000% better than the unwieldy "Button Facade". Kudos on the name re-vamp.

    Lastly, I noticed that if in my skins if I include the Masque version number in the skins the text is positioned differently. So I removed the Masque_Version data field from my Trinity skins, but other than text position, is it important to have this number? I am a bit too busy to dig around and find out myself if anything else will blow up.

    The Trinity Skin pack has 10 skins and I do not have the time to fiddle with text positions right now, but I need to know if I need to find that time so I can properly use the Masque_Version field ;)

    Edit: Oh yeah, many thanks for adding the "Shape" field as well ;D

    Thanks.
    Posted in: General AddOns
  • 0

    posted a message on ButtonFacade (was LibButtonSkin-1.0)
    I would like to see a new optional key added to skins that BF will then add to the button, if the key is available - shape.

    I myself prefer round skins and with the new spell flash alerts in 4.0 I am working on designing a round-button version of a spell flash alert. However, to display the proper square, round or other shaped spell alert, there needs to be a way to query the button to determine the intended shape of the skin by the skin designer. A index can then be added to the button's table such as button.__bfskin_shape = "[square|round|other]", or at the very least add a method to BF such as BF:GetShape() which returns the shape key for the button skin if available, nil otherwise.
    Posted in: General AddOns
  • 0

    posted a message on DrDamage - Official Thread
    Quote from Gagorian
    I'm not exactly sure how I'll work around this, I need to look into it. Have you asked from the Macaroon author as well?


    Perhaps refresh the buttons on the event PLAYER_TALENT_UPDATE. I will look into it, however, from my end :)
    Posted in: General AddOns
  • 0

    posted a message on LilSparky's Workshop -- Official Thread
    As long as I have access to the data, I should be able to get sorts for LSW working. I just have to make my sorting more modular as it is fairly hard-coded right now. I planned on adding new sort methods, but did not figure adding ones based on another addon's data.


    when you say the pricing does not update, you mean it doesn't draw or it draws but is 0's until you force an update?
    That would be correct. The progress bars moves along fine, but the data, even though it is there, does not update with pricing until I do something that causes an update in my frame.


    also, you should probably add a check in there somewhere to make sure the right version is available. this is a complete rewrite, practically. the old lsw was a mess. something like:
    Heh, I did that, though I pulled the Version number from the addon meta data.
    Posted in: General AddOns
  • 0

    posted a message on LilSparky's Workshop -- Official Thread
    I got a plugin working no problem :) So, I suppose you can not add or remove the frame support code I gave you. I will have the plugin available in my next update. The only issue I am having is that the pricing does not update once the frame shows until I click on a tradeskill or scroll the frame. Trying to figure out if that is on my end or because this version is still in alpha :)

    Now, as for the sorting, I can easily add in new sorting methods. And that would be my job anyhow :D I will just add the sort option along with the sorting code in the plugin. The question will be if the data is reachable from Jobber.
    Posted in: General AddOns
  • 0

    posted a message on LilSparky's Workshop -- Official Thread
    Yes, that is what I mean, like the init code...and now that I think of it, just like you said, I could have done exactly what I was talking about and made a plugin instead of requesting on having my code included ;D

    I am going to write support for LDW into Jobber via a plugin and see how it goes. I merely wrote the frame support as you had for ATSW and Skillet as I figured that is the way you wanted it to go :p
    Posted in: General AddOns
  • 0

    posted a message on LilSparky's Workshop -- Official Thread
    Well, my thought would be to go along the lines of ButtonFacade. Create a core library for the data and perhaps a GUI to provide changing how that data is displayed. Then any addon that wants to add support merely throws it's tradeskill button to LSW to be modified. All the support code would be in the tradeskill addon and you would not have to worry about any tradeskill addons themselves. What is nice about this system is if a tradeskill addon author does not want to provide support, a thrird party could make a plugin addon to throw the tradeskill addons buttons at LSW for modification.

    Not sure if I explained that clearly :) However, I think if you look at ButtonFacade as a model, it should then become clear (I hope)
    Posted in: General AddOns
  • 0

    posted a message on LilSparky's Workshop -- Official Thread
    Hiya Sparky,

    I created a new tradeskill addon called Jobber and some are requesting compatibility with you addon. So, using your frame support system, I have created the needed code. It still needs some work and of course you would need adjust your toc if you choose to add support -

    -- LSW Jobber Interface
    
    do
        local buttonNamePattern, buttonTextNamePattern = "JobberSkill(%d+)", "JobberSkill%d"
    
        local function getWidth()
            return JobberHF:GetWidth()
        end
    
        local function initButton(i)
    
            local button = _G["JobberSkill"..i]
    
            if (button and not button.LSW) then
    
                button:SetScript("OnShow", function() LSW:SkillButtonShow(button) end)
                button:SetScript("OnHide", function() LSW:SkillButtonHide(button) end)
    
                LSW:CreateDynamicButtons(i, "JobberSkill"..i, JobberFrame)
    
                button.LSWValue = _G["LSWTradeSkillValue"..i]
                button.LSWCost =_G["LSWTradeSkillCost"..i]
                button.LSWLevel = _G["LSWTradeSkillItemLevel"..i]
    
                button.LSW = true
            end
    
            return button
        end
    
        local function updateWindow()
    
            local num, button = 1
    
            repeat
    
                button = initButton(num)
    
                if (button and button:IsShown()) then
    
                    if (button.isHeader) then
                        button.LSWValue:Hide()
                        button.LSWCost:Hide()
                        button.LSWLevel:Hide()
                    else
                        button.LSWValue:Show()
                        button.LSWCost:Show()
                        button.LSWLevel:Show()
                    end
                end
    
                num = num + 1
    
            until (not button)
    
            LSW:CreateTimer("updateJobber", 0.1, LSW.UpdateData)
        end
    
        local function Init()
    
            hooksecurefunc(Jobber, "frameShow", updateWindow)
            hooksecurefunc(Jobber, "frameUpdate", updateWindow)
    
            LSW.RefreshWindow = updateWindow
    
            LSW.GetSkillListWidth = getWidth
    
            LSW.parentFrame = JobberListScrollFrame
    
            LSW.buttonNamePattern = buttonNamePattern
            LSW.buttonTextNamePattern = buttonTextNamePattern
    
        end
    
        function Test()
            if Jobber then
                return true
            end
            return false
        end
    
        LSW:RegisterFrameSupport("Jobber", Test, Init)
    end
    Posted in: General AddOns
  • 0

    posted a message on Can a talented dev please update ADAPT?
    Mainly because it is a bad habit. The toc number is a declaration by the author that as far as they can determine, the addon complies with the API of that interface version.

    Changing the toc number does not make an addon up-to-date or compatible, but rather just lies to the addon system about the addon's state.
    Posted in: AddOn HELP!
  • 0

    posted a message on DrDamage - Official Thread
    The reason for the pattern matching has to do with Macaroon adding () to the end of spells. This is done for several reasons, but this is not the place to get into it :)

    However, strangely enough, I was coming here to post a revised portion of that particular code to account for macros using "#showtooltip". If Gagorian, or whomever is posting the updates, would like here is the snippet -

        if IsAddOnLoaded("Macaroon") then
            local func = function(button)
                if button.macroshow then
                    return nil, string_match(button.macroshow,"[^%(]+"), button.macrorank
                end
                if button.macrospell then
                    return nil, string_match(button.macrospell,"[^%(]+"), button.macrorank
                end
            end
            ABrefresh["MacaroonButton"] = function()
                for _, button in pairs(Macaroon.Buttons) do
                    ABtable[button[1]:GetName()] = func
                end
            end
        end
    Posted in: General AddOns
  • 0

    posted a message on What breaks InterfaceOptionsFrame_OpenToCategory?
    My first suspect would be LibBetterBlizzOptions.

    It already does one thing it should not do, and that is move the Blizz Interface Options from the strata "HIGH" to "FULLSCREEN_DIALOG", something that is totally unneeded and actually causes issues for me.
    Posted in: Lua Code Discussion
  • 0

    posted a message on DrDamage - Official Thread
    Sounds like the starting of an addon idea :cool:

    A core library (like LibButtonFacade) provides the functionality while modules provide the data, much like how Button Facade skin modules provide the skin data.

    Not fully fleshed out, but I can see it happening...

    I would work on it myself, but I am too busy :p
    Posted in: General AddOns
  • 0

    posted a message on ButtonFacade (was LibButtonSkin-1.0)
    Quote from Gello »

    1) Is this an embedded library or a dependency?

    An optional dependency. An addon registers it's button objects with BF, BF then handles the skinning of the button.


    2) I see someone added support for TrinketMenu without me being involved:
    http://github.com/jazzyfox/trinketmenu_buttonfacade/tree/master
    Why is mod author support required at the button creation level?

    Support can be imbedded in an addon or via plugin. My own addon, Trinity Bars, has it's own skinning engine which I do not plan to abandon. Also, I do not plan to include BF-specific code in my addon. However, I did write a plugin that will override Trinity's own skinning engine if BF and the plugin are installed.

    BF supplies the skinning engine. It is up to the addon and/or plugins to tell the engine which buttons to skin. An author such as yourself is not obligated to support BF in your addon code and as long as you don't mind others writing plugins, your addons can be skinned via BF with thrid-party plugins. I wrote my own plugin just because it is really rather simple :)


    3) Is there any documentation anywhere for OPTIONALLY supporting this? Or is support an all-or-nothing thing. You can disable its features, but you must use it to support it?

    I think the best way to optionally support BF is to write a plugin or let someone else write one. Tuller of Bongos has no plans to maintain BF support, but a plugin was written for Bongos3 that lets users who want BF support in Bongos have it. Tuller does not have to do a thing in his own code to make BF work with Bongos, mainly because of the way BF is designed to work.


    Stuff like "then if you're still experiencing problems saving the colors, inform the actionbar addon authors." just scares the crap out of me. Don't get me wrong, I'd like to support it, but I don't want the hassle of keeping up with other people's mods just to keep up with my own.


    I think perhaps jj could word this better :) BF is not going to support any addon specifically, like CyCircled does. If someone wants an addon to be skinned by BF, the addon either needs the author to add support *OR* another person (or the author themselves) needs to write a plugin.

    In the end, you don't need to do a thing Gello. I think your addons are popular enough that someone will write a plugin to add BF support. I myself prefer to write and maintain my own plugin because in the end it is easier and quicker than answering a bunch of questions on *how* to write one that will work with Trinity Bars :)
    Posted in: General AddOns
  • 0

    posted a message on ButtonFacade (was LibButtonSkin-1.0)
    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.
    Posted in: General AddOns
  • To post a comment, please or register a new account.