I just want to inquire about the status of this addon...
Well in terms of AutoBar I had to specifically set the size of buttons right after creating their frame. Without that they would skin with minsicule 2x2 pixel icons or something. I do not think this is a BF issue but just something that changed in how Blizzard is doing things. At any rate the fix was simple and required no changes to BF. As far as I am concerned all is well.
There was one other gotcha. The skinned callback is now secure code so you need to adjust for that if necessary as well. If you just squirelled info away all is fine. If you did anything more like call non-protected functions you would run into issues. (I only ran into this because I added debug code to it that called some local functions)
....Localozation\enUS:1: Cannot find a lib instance of "AceLocale-3,0"
I use the german client
This would happen if you run disembeded and dont properly handle dependencies. Delete the ButtonFacade folder from Addons. Download a new version of ButtonFacade from files.wowace.com. Do NOT use WAU or anything else, get a zip from the website and unzip it into your Addons folder. Did your problem go away?
...I played with the plugin Jazzyfox wrote for TrinketMenu (with some of StormFX's skins which are very cool) and it works very well. I'll likely keep it as a separate plugin.
1) Thank goodness you are back Gello. I was starting to dread the day ItemRack broke and I would have to abandon it.
2) For some of us ButtonFacade is a huge improvement over cyCircled. cyCircled continuously broke AutoBar or caused uneccessary lag or any number of stupid things that wasted my time. Furthermore its bassAckwards nature meant its support was always flaky. ButtonFacade just works, and more than that it works appropriately without forcing itself onto me against my will. That is why within 2 or 3 weeks of being told about ButtonFacade cyCircled was kicked to the curb and ButtonFacade adopted as the only skinning option for AutoBar. The amount of code devoted to skinnng dropped to about an 1/8th of what it used to be to "support" cyCircled, and that is without counting the cyCircled module itself.
3) The code and data to support skinning if ButtonFacade is present is very minimal. I would highly recommend just plain supporting it up front.
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.
...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...
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?
No no, its not messing things up its just the way profiles with buttonfacade and autobar works together. I have the basic bar in autobar setup for all my toons they all share the same buttons etc. but with the way profiles work in buttonfacade the settings are stored in the autobar savedvariables and not in the buttonfacade one like in cycircled. So what this means is when i set the basic bar to a certain skin it stays that skin for all toons reguardless of the the profile in buttonfacade. It's just different from cycircled in that cycircled itself handled profiles for different toons whereas now Autobar does.
Right. Again, at the moment AutoBar has not fully implemented the profiling system and preferences that ButonFacade has. At some point it will and then you will be able to have custom settings for different toons regardless of how AutoBar shares other settings for a given Bar.
...Edit: Ok figured out what was happening, has to do with the way AutoBar handles its bars. Basically there's three seperate bars: basic, class, and extra. Autobar saves the skin on a per bar basis, This is why i'd keep getting the same skin no matter what profile i used in ButtonFacade. Since autobar saves the skin and ButtonFacades profile system basically does nothing with autobar installed it makes customization on different toons pretty much a pain, unless i make a seperate bar in autobar for each toon. Which i don't plan on doing, rather dump BarFacade and just use the blizzard skin instead of reworking autobar for each toon i have.
Not quite sure what you mean. Are you saying AutoBar is messing up ButtonFacade for all other mods using it? Or just that currently AutoBar only cares about the individual bar settings (settings at the AutoBar level are currently ignored). I intend to have higer settings cascade but it is not implemented that way at the moment.
...On AutoBar, Onyx Classic looked correct. The mouseover highlight texture was below the border, and you only saw yellow in the arrow at the top of the button. On infinibar, however, the highlight was above the border. So that the whole skin glowed yellow. I attempted a reload, and then AutoBar was doing it, too, in the main bar, but the popups were still correct. Another reload fixed Autobar back to being right, but IB just wasn't working.
Yeah weird. I changed to Caith today and noticed it was hiliting properly everywhere. Then after a reload it was messed, no more hiliting. Some weird difference between login and reload vs skining.
I am just catching up on the coloring and text repositioning thing, so heres my 2 cents plus a 3rd cent:
Quote from StormFX »
Some skins were designed to accept color input (Serenity), others weren't (Onyx). And to be perfectly honest, if the skin wasn't designed for color changes, the user shouldn't be able to change it.
This only makes sense if we all used the exact same monitor, with the exact same gamma settings, in identical rooms with the exact same lighting, objects murals whatever, and had the exact same gene codings for the visual systems in our eyes and brains.
Since this is not the case you cannot claim that since it looks good to you as an author it also looks good to a user since that is simply not true. It might be true but it is not guaranteed true.
So I think as stated before an option to adjust color makes sense. You should also be able to just turn off the optional coloring and use the skin as designed.
Now on this topic I have an issue currently with the border color and shape. Blizzard colors it green. It has rounded edges and looks icky on say DreamLayout which is square. Additionally AutoBar adds some other border colors (blue for spell buttons), dont know if I will add a color for macro buttons yet.
So can we add changing the border (by the skin author) as well as a set of colors for it? Either some predefined set of colors or a callback mechanism to get them. I can volunteer to add the coloring stuff for borders at any rate since I have to write that code anyway.
Good grief. Well which mods actually let u adjust this in their UI and which one does the best job of it? Lets get its author to volunteer moving that into ButtonFacade. I know AutoBar does not adjust this.
All this skinning is kool and all but what about animating some stuff. Right now the only animation is showing the hilite layer on mouseover. I would like to see the glow maybe intensifying as you stay over the button then fade off when you leave.
FadeOut could potentially be done this way as well. This would let a skin do things like shrink to say tiny dots instead of fading out. Or fade out by burning up and exploding away at the end. Etc.