I have a couple of bars.
One or more use Shift to page:
When I try to edit another Groupname textbox, and I use the shift key to give me a capital char, then editing stops.
The moment I press the Shift key, I see the other paging bars page, and Im out of the editbox.
As of Revision 67996:
Most of the issues listed in my last post are fixed in this version.
Added support for DogTags to control the Flash, Border, and Icon Highlight. Read up on the documentation in /dog, and post questions here for me to answer. This adds near total control of your highlighting to the DogTags. Highlight Dog Tags work as follows: The highlight will be active with the first color code returned by the tags. If no color is returned, the highlight will not be visible.
Added support for Button Flashing and value tracking in dogtags. I'll get some examples written up tomorrow and post them here for you guys to play with.
I added the Revision number to the IB2 FuBar tooltip.
Quote from StormFX »
So you're going write another bar/button skinning mod similar to cyCircled? Or are you planning on adding skinning support for IB that also skins everything that cyCircled skins, as well? Not to mention that there's various skin packs that you'd have to either add support for or include (with authors' permissions, of course). Meh. Trinity Bars has its own skinning engine yet retains cC support. >.<
P.S. cyCircled will be out-of-date when it stops working. :P
I guess I can keep the support for cyCircled around... but I hate certain inconsistencies it employs.
Quote from razoon »
Another error I got when using a Silk bandage:
Date: 2008-04-03 11:36:34
ID: 61
Error occured in: Global
Count: 1
Message: ..\AddOns\InfiniBar-2.0\IB_Button.lua line 724:
GetSpellName(): Invalid spell slot
Fixed as of Revision 67996.
Quote from razoon »
About the Group textboxt edit issue:
I have a couple of bars.
One or more use Shift to page:
When I try to edit another Groupname textbox, and I use the shift key to give me a capital char, then editing stops.
The moment I press the Shift key, I see the other paging bars page, and Im out of the editbox.
I know what's going on here now, and I'll see what I can do to eliminate this issue.
Quote from razoon »
Is it possible to give empty buttons the color black instead of transparant?
Thank you so much for the macro states =) Another feature request though: negative spacing on bars. Using the VolGold skin, there's so much space between the buttons, I usually set around -5 or -6 spacing in bt3 or bongos. Would be much appreciated.
Yes, negative button spacing would be nice, too. Forgot about that since I'm currently using big fat Onyx.
If you're writing your own skinning solution, please separate "gloss" textures from everything else. For one, most glossy skins are too glossy and obscure the actual icons too much, especially at smaller sizes; if it were a separate texture, its alpha could be independently adjusted. For two, it's pretty annoying when I want to change the border color, and it changes the gloss color too... dark gray "gloss" is just hideous, which renders otherwise nice skins like SimpleSquare unusable for me. :(
Quote from Fulnir »
When fading bars to 0% percent (hiding them) the tooltips still occur when I mouseover the location of the bars. That's really annoying tbh.
I noticed this last night after my post about the other stuff. I have an always-hidden bar that I use for character-specific keybinds, since I don't really want to deal with maintaining full sets of character-specific keybinds for all my characters when I only need a few things (i.e. druid has form macros keybound, but I want those keybindings available for other things on other characters).
Quote from razoon »
Do I need to delete the dependencie subfolders of the addon if I use standalone libs?
Yes. Otherwise you're still loading the embedded copies in addition to the standalone copies. Also delete embeds.xml and remove the line calling embeds.xml in the .toc file, to avoid "missing file" errors in FrameXML.log (slows down loading).
Quote from jjsheets »
Actually I prefer to have some of my testers use the embedded libs. If none do, I'll never find issues related to the embedded libs without extra testing... and I'm lazy when it comes to testing this sort of stuff.
Hey, I pointed out the missing embeds right away, and I haven't actually used embedded libs since I discovered they existed and could be disembedded. :P
I guess I can keep the support for cyCircled around... but I hate certain inconsistencies it employs.
What inconsistencies? I'd be more than happy to perhaps branch off and work on an Ace3 version of it. I'd need help, though, as my LUA isn't up to par. Awhile back, someone sent me some code that basically globalized the skinning, but I wasn't sure how it worked. If we could come up with a modular system that mod & skin authors could easily hook into, we'd be set.
Yes, negative spacing would be nice, too. Forgot about that since I'm currently using big fat Onyx.
Onyx is NOT fat! It's big-boned! :P
If you're writing your own skinning solution, please separate "gloss" textures from everything else. For one, most glossy skins are too glossy and obscure the actual icons too much, especially at smaller sizes; if it were a separate texture, its alpha could be independently adjusted. For two, it's pretty annoying when I want to change the border color, and it changes the gloss color too... dark gray "gloss" is just hideous, which renders otherwise nice skins like SimpleSquare unusable for me.
I don't think IB is rendering the skins correctly. But you're right about most of what you're saying. If I knew more about LUA, I have some ideas for a branched version of cC (that includes the "gloss" being its own texture AND native cool down counts) that I'd love to try out. I just suck at LUA. >.<
I think the best solution for the cyCircled "problem" would be to eliminate addon-specific skins, and just provide an API, kind of like SharedMedia. Let addon authors implement their own support, specifying what things to apply skins to (and keeping track of which addon components are skinned), and registering callbacks to keep track of when the user changed the skin. This would also make it trivial to use different skins on different addons (or even different parts of the same addon).
Also see my previous post about the troublesome gloss effect.
I think the best solution for the cyCircled "problem" would be to eliminate addon-specific skins, and just provide an API, kind of like SharedMedia. Let addon authors implement their own support, specifying what things to apply skins to (and keeping track of which addon components are skinned), and registering callbacks to keep track of when the user changed the skin. This would also make it trivial to use different skins on different addons (or even different parts of the same addon).
While that's certainly a possibility, it seems to me that it would allow the add-on complete control over the skin, etc., which defeats the purpose of cyCircled (applying skins to mods whose authors don't want to implement them).
I'm just trying to get some ideas. The biggest issue is the method in which button/bar type mods are written.
Thank you so much for the macro states =) Another feature request though: negative spacing on bars. Using the VolGold skin, there's so much space between the buttons, I usually set around -5 or -6 spacing in bt3 or bongos. Would be much appreciated.
Done. Get Revision 68045.
Quote from Fulnir »
When fading bars to 0% percent (hiding them) the tooltips still occur when I mouseover the location of the bars. That's really annoying tbh.
And Fixed. Also in Revision 68045.
Quote from Phanx »
If you're writing your own skinning solution, please separate "gloss" textures from everything else. For one, most glossy skins are too glossy and obscure the actual icons too much, especially at smaller sizes; if it were a separate texture, its alpha could be independently adjusted. For two, it's pretty annoying when I want to change the border color, and it changes the gloss color too... dark gray "gloss" is just hideous, which renders otherwise nice skins like SimpleSquare unusable for me. :(
This is the major reason why I want a new, or updated, skinning solution. Because of the way cyCircled skins are set up, I have to color the overlay as well, just to get the border to color in. This is inconsistent, it should be a texture for the border (i.e., the normal texture in the group that buttons have), and the overlay or gloss texture. If this is changed in cyCircled, it would need to be changed/updated for all skins at the same time. I'd rather start from scratch, using a simple library to allow me to skin a button precisely with a function call. The kind of lib I'm thinking of would also make it simple for me to allow different skins for different groups, and even for different buttons within a single group. If someone wants to take a crack at doing this, I'd be happy to help out (especially with what interface I'd like), but I won't get around to doing it myself until maybe the weekend or next week. I still have to do the presets system.
Hey, I pointed out the missing embeds right away, and I haven't actually used embedded libs since I discovered they existed and could be disembedded. :P
There were issues with my use of LibSharedMedia-3.0 that I only became aware of after an embedded libs user pointed some errors out to me. I'm horrible at making sure all of the embeds are just right, especially when it works fine for me. :p
Quote from StormFX »
What inconsistencies? I'd be more than happy to perhaps branch off and work on an Ace3 version of it. I'd need help, though, as my LUA isn't up to par. Awhile back, someone sent me some code that basically globalized the skinning, but I wasn't sure how it worked. If we could come up with a modular system that mod & skin authors could easily hook into, we'd be set.
Essentially I'd need a function that I could call, passing in the button I want skinned, along with the icon texture and flash texture, etc., and the skin I want the button to use, and have the lib set it all up for me. Without the border and the gloss texture mixed into one.
I would also need, much like LSM-3, the ability to get the list of skins, and the order they should be presented in (for GUI selection).
I don't think IB is rendering the skins correctly. But you're right about most of what you're saying. If I knew more about LUA, I have some ideas for a branched version of cC (that includes the "gloss" being its own texture AND native cool down counts) that I'd love to try out. I just suck at LUA. >.<
I really like the idea of using a library to skin buttons, instead of cyCircled's way of skinning buttons after the fact. It just seems much cleaner, IMO. Also, I don't think that Cooldown counts should be included in a button skinning solution. Do one thing well, use OmniCC for the cooldown counts. :)
Quote from StormFX »
While that's certainly a possibility, it seems to me that it would allow the add-on complete control over the skin, etc., which defeats the purpose of cyCircled (applying skins to mods whose authors don't want to implement them).
Yet if an author wants to have cyCircled skin his buttons, he still has to program, and worse, he has to commit his changes to cyCircled, instead of his own addon. An API gives that control to the addon author. When creating new buttons, you generally create the frames and textures you need and set their textures up. With a library, you'd be able to create the frames and textures up, then tell the library to set the textures and positioning up according to the default skin. Switching skins would be easy to do in the GUI or console commands. This ends up being less work for the button author to do, since an entire portion of the system is contracted out to the library.
I'm just trying to get some ideas. The biggest issue is the method in which button/bar type mods are written.
Adding cyCircled support can be very daunting to an unfamiliar author. Having a few functions to call from a library, and having the control over when and how this occurs, is golden.
Other faults of cyCircled:
CyCircled assumes static lists of buttons. As you all know, IB2 is anything but static. You can add and remove button groups at will. But these new groups will not show up in cyCircled's list of button groups. For a while there, I had them automatically being set up skinned, but now it isn't working anymore. So now you have to /reloadui just so you can make sure they are skinned. A library would solve this issue cleanly and efficiently.
For that matter, why should I have to go to a different addon to control the look of buttons in IB2, or Bongos, or Bartender? Each of these addons should be able to set up their skins themselves, within their configuration. No more telling users to get cyCircled and use it, it's now part of the interface.
For a split second after loading up, you can see the non-skinned look of the buttons. With a library, the buttons would be set up from scratch using the intended skin. Minor complaint, but it's there.
I think I'm definitely going to make the library, and will be getting input from other Actionbar addon developers on what they'd like. I'm going to get presets programmed tonight or tomorrow, fix a few straggling bugs, then I'm going to work on the button skinning library.
Unfortunately, today is VERY busy for me. I have to leave for work in about ten minutes (two hours earlier than normal today), and I'll be working late tonight too. That said, I don't think the presets are going to be all that difficult to set up.
I just wanted to drop a line and let you know you were right lol. You did have Cy support I just had a older version of Cy. I also think that skinning from a library would be a lot easier and cleaner. Most of the skinns from Cy are pretty easy to pull out and you could even go so far as pulling skins from candy bar or surfaces or something like that.
Great work on your addon, its weird to have you and CnC back and actively codeing your addons though lol so hard to choose :) but I like IB for lots of reassons but one main one is a pet bar. Its hard to manual set one up in FB right now and I dont want to get another addon just to have a pet bar.
Keep up the good work, IB has always been a good product.
(Truncated)I think I'm definitely going to make the library, and will be getting input from other Actionbar addon developers on what they'd like. I'm going to get presets programmed tonight or tomorrow, fix a few straggling bugs, then I'm going to work on the button skinning library.
The more you talk about it, the more I'm liking the idea. Again, the problem I see is that some bar/button authors may not want to use the library to skin the add-on, which will leave users hanging. However, I don't think it'd be difficult to find a compromise (which I'll explain).
At first, I was thinking that we could use LSM, but that won't work as the library only stores the tables for easy access to the files. What we'd need is a back-end that provides not only tables for the skins (buttonskins -> skinname -> attribute=value), but functions that add-on authors can call on to access the data AND functions for skin authors to add their skins via separate "add-ons" (there's a good reason for this).
As far as a "compromise" goes, we could simply write a front-end to it that allows for things such as global skin selection, skin tweaking and the ability to skin non-compliant add-ons via modules or something.
As far as the actual skinning methods, I (as a skinner) have some ideas on how the skins should set up (lots of hours fooling with cC).
First of all, each state/feature should be its own texture. As Phanx mentioned, having the border and highlight as the same texture makes for some ugly results on highlights or custom coloring.
Secondly, "layer" order is very important and after fooling with it awhile, I have an order that should work for all skins.
Finally, something that has to be "adjustable" is the scale of the individual components. For example, you're going to always want as much of the skill/spell icon showing as possible. IE, with rounded buttons and square buttons with wider borders, the icon size is reduced a bit.
I've got a ton more ideas, but I don't want to flood this post with unrelated garble. Feel free to send me a PM for more detailed information. Or, we could start a separate post.
But before I go, we have to decide the most important thing! The name! :D Some ideas:
- LibBarSkins-x.x & BarSkins (Though misleading, as it's only skinning the buttons)
- LibButtons-x.x & Buttons (Simple, accurate, effective)
- Or some other variation of "Icon", "Button" and/or "Skin". We also need it to be usable with the likes of <name>_SkinName ("Lib" removed on the skin names), of course.
If we can figure that out, I'll start a suggestions/feedback thread and we can go from there.
I've started a discussion thread on this over in the Addon Ideas thread. Take all discussion of a new Skinning solution here. I'll respond to the discussions here in that thread tonight.
[2008/04/05 00:29:58-2557-x2]: InfiniBar-2.0\IB_Button.lua:1035: Usage: GetPetActionInfo(index)
InfiniBar-2.0\IB_Button.lua:1035: in function <Interface\AddOns\InfiniBar-2.0\IB_Button.lua:1028>
<string>:"local _G = _G;...":57: in function <[string "local _G = _G;..."]:14>
(tail call): ?:
<in C code>: in function `xpcall'
LibDogTag-3.0\LibDogTag-3.0.lua:299: in function <Interface\AddOns\LibDogTag-3.0\LibDogTag-3.0.lua:288>
LibDogTag-3.0\Events.lua:559: in function <Interface\AddOns\LibDogTag-3.0\Events.lua:489>
---
[2008/04/05 00:29:58-2557-x9]: InfiniBar-2.0\IB_Button.lua:1035: Usage: GetPetActionInfo(index)
InfiniBar-2.0\IB_Button.lua:1035: in function <Interface\AddOns\InfiniBar-2.0\IB_Button.lua:1028>
<string>:"local _G = _G;...":11: in function <[string "local _G = _G;..."]:7>
(tail call): ?:
<in C code>: in function `xpcall'
LibDogTag-3.0\Compiler.lua:2196: in function <Interface\AddOns\LibDogTag-3.0\Compiler.lua:2183>
LibDogTag-3.0\Events.lua:446: in function <Interface\AddOns\LibDogTag-3.0\Events.lua:249>
LibDogTag-3.0\Events.lua:648: in function `FireEvent'
LibDogTag-Unit-3.0\Categories\Auras.lua:186: in function `func'
LibDogTag-3.0\Events.lua:552: in function <Interface\AddOns\LibDogTag-3.0\Events.lua:489>
---
[2008/04/05 00:30:00-2557-x1]: InfiniBar-2.0\IB_Button.lua:1035: Usage: GetPetActionInfo(index)
InfiniBar-2.0\IB_Button.lua:1035: in function <Interface\AddOns\InfiniBar-2.0\IB_Button.lua:1028>
<string>:"local _G = _G;...":11: in function <[string "local _G = _G;..."]:7>
(tail call): ?:
<in C code>: in function `xpcall'
LibDogTag-3.0\Compiler.lua:2196: in function <Interface\AddOns\LibDogTag-3.0\Compiler.lua:2183>
LibDogTag-3.0\Events.lua:446: in function <Interface\AddOns\LibDogTag-3.0\Events.lua:249>
LibDogTag-3.0\Events.lua:648: in function `FireEvent'
LibDogTag-Unit-3.0\Categories\Auras.lua:190: in function `func'
LibDogTag-3.0\Events.lua:552: in function <Interface\AddOns\LibDogTag-3.0\Events.lua:489>
---
They are probably related and I'm sorry if some of them are redundant, just wanted to show you what my bad picked up.
I also attached a pic of the fading problem as well, I'm hoovering one of my hidden bars and the bar is right where the tooltip is, the buttons are even clickable while 0% faded. Using revision 68045.
don't know if it's already being asked. but will there be any chance to create something like the micromenu? charbutton, optionsbutton, LFG and so on?
I may add this at a later date, but for now I suggest using FuBar_MicroMenuFu, or a similar addon. You can also use the keybinds to bring up the pages. The difficulty with this is that these buttons are not square, and thus will be slightly difficult to skin. I may, however, take a look at MicroMenuFu's icons and see how it's doing it.
Quote from Fulnir »
Got these three erros while hoovering the petbar:They are probably related and I'm sorry if some of them are redundant, just wanted to show you what my bad picked up.
This should be fixed, as of Rev. 68109.
I also attached a pic of the fading problem as well, I'm hoovering one of my hidden bars and the bar is right where the tooltip is, the buttons are even clickable while 0% faded. Using revision 68045.
Try changing the fade amount up, then resetting it down to 0%. Let me know if you're still having this happen. Also, does the bar have any state changes? Or is it simply a hidden bar? I was not able to reproduce this on my end.
The difficulty with this is that these buttons are not square, and thus will be slightly difficult to skin. I may, however, take a look at MicroMenuFu's icons and see how it's doing it.
MicroMenuFu doesn't skin its buttons. :P
Edit:
Your OptionalDeps is missing some stuff; it should look like this:
## OptionalDeps: LibRock-1.0, LibFuBarPlugin-2.0, LibDogTag-3.0, LibDogTag-Unit-3.0, LibSharedMedia-3.0, LibSpecialEvents-Aura-3.0, DrDamage
Yeah, I took a look at it, then looked at the Blizzard icons. I'll play around with the icons and see if I can't extract something useful out of 'em.
Edit:
Your OptionalDeps is missing some stuff; it should look like this:
## OptionalDeps: LibRock-1.0, LibFuBarPlugin-2.0, LibDogTag-3.0, LibDogTag-Unit-3.0, LibSharedMedia-3.0, LibSpecialEvents-Aura-3.0, DrDamage
Try changing the fade amount up, then resetting it down to 0%. Let me know if you're still having this happen. Also, does the bar have any state changes? Or is it simply a hidden bar? I was not able to reproduce this on my end.
This worked, they are all gone now. Thank you.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have a couple of bars.
One or more use Shift to page:
When I try to edit another Groupname textbox, and I use the shift key to give me a capital char, then editing stops.
The moment I press the Shift key, I see the other paging bars page, and Im out of the editbox.
Most of the issues listed in my last post are fixed in this version.
Added support for DogTags to control the Flash, Border, and Icon Highlight. Read up on the documentation in /dog, and post questions here for me to answer. This adds near total control of your highlighting to the DogTags. Highlight Dog Tags work as follows: The highlight will be active with the first color code returned by the tags. If no color is returned, the highlight will not be visible.
Added support for Button Flashing and value tracking in dogtags. I'll get some examples written up tomorrow and post them here for you guys to play with.
I added the Revision number to the IB2 FuBar tooltip.
I guess I can keep the support for cyCircled around... but I hate certain inconsistencies it employs.
Fixed as of Revision 67996.
I know what's going on here now, and I'll see what I can do to eliminate this issue.
Not yet, but I'll add it to the list.
If you're writing your own skinning solution, please separate "gloss" textures from everything else. For one, most glossy skins are too glossy and obscure the actual icons too much, especially at smaller sizes; if it were a separate texture, its alpha could be independently adjusted. For two, it's pretty annoying when I want to change the border color, and it changes the gloss color too... dark gray "gloss" is just hideous, which renders otherwise nice skins like SimpleSquare unusable for me. :(
I noticed this last night after my post about the other stuff. I have an always-hidden bar that I use for character-specific keybinds, since I don't really want to deal with maintaining full sets of character-specific keybinds for all my characters when I only need a few things (i.e. druid has form macros keybound, but I want those keybindings available for other things on other characters).
Yes. Otherwise you're still loading the embedded copies in addition to the standalone copies. Also delete embeds.xml and remove the line calling embeds.xml in the .toc file, to avoid "missing file" errors in FrameXML.log (slows down loading).
Hey, I pointed out the missing embeds right away, and I haven't actually used embedded libs since I discovered they existed and could be disembedded. :P
What inconsistencies? I'd be more than happy to perhaps branch off and work on an Ace3 version of it. I'd need help, though, as my LUA isn't up to par. Awhile back, someone sent me some code that basically globalized the skinning, but I wasn't sure how it worked. If we could come up with a modular system that mod & skin authors could easily hook into, we'd be set.
Onyx is NOT fat! It's big-boned! :P
I don't think IB is rendering the skins correctly. But you're right about most of what you're saying. If I knew more about LUA, I have some ideas for a branched version of cC (that includes the "gloss" being its own texture AND native cool down counts) that I'd love to try out. I just suck at LUA. >.<
Also see my previous post about the troublesome gloss effect.
While that's certainly a possibility, it seems to me that it would allow the add-on complete control over the skin, etc., which defeats the purpose of cyCircled (applying skins to mods whose authors don't want to implement them).
I'm just trying to get some ideas. The biggest issue is the method in which button/bar type mods are written.
Done. Get Revision 68045.
And Fixed. Also in Revision 68045.
This is the major reason why I want a new, or updated, skinning solution. Because of the way cyCircled skins are set up, I have to color the overlay as well, just to get the border to color in. This is inconsistent, it should be a texture for the border (i.e., the normal texture in the group that buttons have), and the overlay or gloss texture. If this is changed in cyCircled, it would need to be changed/updated for all skins at the same time. I'd rather start from scratch, using a simple library to allow me to skin a button precisely with a function call. The kind of lib I'm thinking of would also make it simple for me to allow different skins for different groups, and even for different buttons within a single group. If someone wants to take a crack at doing this, I'd be happy to help out (especially with what interface I'd like), but I won't get around to doing it myself until maybe the weekend or next week. I still have to do the presets system.
There were issues with my use of LibSharedMedia-3.0 that I only became aware of after an embedded libs user pointed some errors out to me. I'm horrible at making sure all of the embeds are just right, especially when it works fine for me. :p
Essentially I'd need a function that I could call, passing in the button I want skinned, along with the icon texture and flash texture, etc., and the skin I want the button to use, and have the lib set it all up for me. Without the border and the gloss texture mixed into one.
I would also need, much like LSM-3, the ability to get the list of skins, and the order they should be presented in (for GUI selection).
I really like the idea of using a library to skin buttons, instead of cyCircled's way of skinning buttons after the fact. It just seems much cleaner, IMO. Also, I don't think that Cooldown counts should be included in a button skinning solution. Do one thing well, use OmniCC for the cooldown counts. :)
Yet if an author wants to have cyCircled skin his buttons, he still has to program, and worse, he has to commit his changes to cyCircled, instead of his own addon. An API gives that control to the addon author. When creating new buttons, you generally create the frames and textures you need and set their textures up. With a library, you'd be able to create the frames and textures up, then tell the library to set the textures and positioning up according to the default skin. Switching skins would be easy to do in the GUI or console commands. This ends up being less work for the button author to do, since an entire portion of the system is contracted out to the library.
Adding cyCircled support can be very daunting to an unfamiliar author. Having a few functions to call from a library, and having the control over when and how this occurs, is golden.
Other faults of cyCircled:
CyCircled assumes static lists of buttons. As you all know, IB2 is anything but static. You can add and remove button groups at will. But these new groups will not show up in cyCircled's list of button groups. For a while there, I had them automatically being set up skinned, but now it isn't working anymore. So now you have to /reloadui just so you can make sure they are skinned. A library would solve this issue cleanly and efficiently.
For that matter, why should I have to go to a different addon to control the look of buttons in IB2, or Bongos, or Bartender? Each of these addons should be able to set up their skins themselves, within their configuration. No more telling users to get cyCircled and use it, it's now part of the interface.
For a split second after loading up, you can see the non-skinned look of the buttons. With a library, the buttons would be set up from scratch using the intended skin. Minor complaint, but it's there.
I think I'm definitely going to make the library, and will be getting input from other Actionbar addon developers on what they'd like. I'm going to get presets programmed tonight or tomorrow, fix a few straggling bugs, then I'm going to work on the button skinning library.
Unfortunately, today is VERY busy for me. I have to leave for work in about ten minutes (two hours earlier than normal today), and I'll be working late tonight too. That said, I don't think the presets are going to be all that difficult to set up.
I just wanted to drop a line and let you know you were right lol. You did have Cy support I just had a older version of Cy. I also think that skinning from a library would be a lot easier and cleaner. Most of the skinns from Cy are pretty easy to pull out and you could even go so far as pulling skins from candy bar or surfaces or something like that.
Great work on your addon, its weird to have you and CnC back and actively codeing your addons though lol so hard to choose :) but I like IB for lots of reassons but one main one is a pet bar. Its hard to manual set one up in FB right now and I dont want to get another addon just to have a pet bar.
Keep up the good work, IB has always been a good product.
don't know if it's already being asked. but will there be any chance to create something like the micromenu? charbutton, optionsbutton, LFG and so on?
greetings bandicut
Are you sure? Not working here, they're still clickable and tooltips are showing :/
The more you talk about it, the more I'm liking the idea. Again, the problem I see is that some bar/button authors may not want to use the library to skin the add-on, which will leave users hanging. However, I don't think it'd be difficult to find a compromise (which I'll explain).
At first, I was thinking that we could use LSM, but that won't work as the library only stores the tables for easy access to the files. What we'd need is a back-end that provides not only tables for the skins (buttonskins -> skinname -> attribute=value), but functions that add-on authors can call on to access the data AND functions for skin authors to add their skins via separate "add-ons" (there's a good reason for this).
As far as a "compromise" goes, we could simply write a front-end to it that allows for things such as global skin selection, skin tweaking and the ability to skin non-compliant add-ons via modules or something.
As far as the actual skinning methods, I (as a skinner) have some ideas on how the skins should set up (lots of hours fooling with cC).
First of all, each state/feature should be its own texture. As Phanx mentioned, having the border and highlight as the same texture makes for some ugly results on highlights or custom coloring.
Secondly, "layer" order is very important and after fooling with it awhile, I have an order that should work for all skins.
Finally, something that has to be "adjustable" is the scale of the individual components. For example, you're going to always want as much of the skill/spell icon showing as possible. IE, with rounded buttons and square buttons with wider borders, the icon size is reduced a bit.
I've got a ton more ideas, but I don't want to flood this post with unrelated garble. Feel free to send me a PM for more detailed information. Or, we could start a separate post.
But before I go, we have to decide the most important thing! The name! :D Some ideas:
- LibBarSkins-x.x & BarSkins (Though misleading, as it's only skinning the buttons)
- LibButtons-x.x & Buttons (Simple, accurate, effective)
- Or some other variation of "Icon", "Button" and/or "Skin". We also need it to be usable with the likes of <name>_SkinName ("Lib" removed on the skin names), of course.
If we can figure that out, I'll start a suggestions/feedback thread and we can go from there.
They are probably related and I'm sorry if some of them are redundant, just wanted to show you what my bad picked up.
I also attached a pic of the fading problem as well, I'm hoovering one of my hidden bars and the bar is right where the tooltip is, the buttons are even clickable while 0% faded. Using revision 68045.
I may add this at a later date, but for now I suggest using FuBar_MicroMenuFu, or a similar addon. You can also use the keybinds to bring up the pages. The difficulty with this is that these buttons are not square, and thus will be slightly difficult to skin. I may, however, take a look at MicroMenuFu's icons and see how it's doing it.
This should be fixed, as of Rev. 68109.
Try changing the fade amount up, then resetting it down to 0%. Let me know if you're still having this happen. Also, does the bar have any state changes? Or is it simply a hidden bar? I was not able to reproduce this on my end.
MicroMenuFu doesn't skin its buttons. :P
Edit:
Your OptionalDeps is missing some stuff; it should look like this:
## OptionalDeps: LibRock-1.0, LibFuBarPlugin-2.0, LibDogTag-3.0, LibDogTag-Unit-3.0, LibSharedMedia-3.0, LibSpecialEvents-Aura-3.0, DrDamage
Yeah, I took a look at it, then looked at the Blizzard icons. I'll play around with the icons and see if I can't extract something useful out of 'em.
Thanks! Revision 68119 has this updated.
This worked, they are all gone now. Thank you.