• 0

    posted a message on Stop changing our code.

    I understand what it's doing, but almost every part of is undesirable to me.

     

    I don't actually want to use localization injection, ever: if performed on uploaded ZIPs, it essentially produces an untested addon release. Even if the localization code itself is correct (and for \n-containing keys, it recently wasn't), bad localization data can break string.format calls within the addon. In practice, this means that if I used localization injection, I'd have to upload a version as alpha, wait for a modified archive, download that, test it, and reflag the version as release. This seems more annoying than my current approach of exporting and verifying localization data prior to generating an archive locally.

     

    It would be nice if the token replacements could be turned off on a per-project basis. Failing that, it would be nice if the file processor task realized that it made no actual changes, and kept the original ZIP file instead of producing another version of it -- at least then the archive MD5 would be a clear indication of whether or not it changed anything.

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Stop changing our code.

    It's a different project, with localization enabled (but not actually used in a way that allows Curse to substitute anything): I'm comparing https://wow.curseforge.com/projects/opie/files/2351980/download (md5: f3f3...) vs https://www.townlong-yak.com/opie/get/umber5 (md5: 1505...).

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Stop changing our code.

    It still seems to recompress the uploaded ZIP rather than serving the original (even if no files inside the ZIP are changed), which results in mismatched archive MD5 across different download sources. This rather increases the amount of effort required to make sure that curse is still serving the actual code uploaded.

    Posted in: WoW Sites Feedback
  • 0

    posted a message on ButtonFacade (was LibButtonSkin-1.0)
    Few things I've bumped into while implementing support for ButtonFacade:
    • Passing anonymous buttons without providing all optional attributes will cause the library to throw an error - it'll end up calling button:GetName() and concatenating the nil result of that with a string to search the global namespace for default textures. It would be best if it checked that button:GetName() isn't nil before it attempts to find optional textures this way. [libButtonFacade.lua:584]
    • It will not apply highligh/checked/pushed/disabled textures unless the highligh/checked texture objects exist on a button to begin with. This is not the case for freshly CreateFrame()'d buttons; and as :GetHighlightTexture() will put nil into btnlayer, SkinHighlighLayer() will exit prematurely, preventing skin application to a button (exactly the same logic prevents all of the other button-level textures from being applied unless previously utilized). It probably won't hurt anyone to apply the skinning layers to a widget that supports them regardless of whether those layers already exist. If if the "hands-off-my-layers" approach actually appeals to someone, it would be better served by allowing addon authors to pass false for values they wish to avoid having ButtonFacade skin in the btndata table.
    Posted in: General AddOns
  • To post a comment, please or register a new account.