Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
Since I spend quite a bit of time designing and coding interfaces (although not in LUA but in AS3 and Java), one pretty major mistake keeps popping into my view again and again as I try out and configure ace addons. As you can probably tell from the topic: I'm talking about parenting the UIParent.
To be a little bit more precise: I think it is very bad practise when you use the UIParent object as a parent for frames your addons are working with. What you should be doing, imho, is create a parent frame that contains all of you addon's created frames as children. That "container" would then be a child of UIParent.
Why is this useful? Well it simply gives you as an author, the user, and people who might be doing modifications to your addon (maybe as part of a UI-compilation) a lot more control over the appearance of your addon. You get an additional layer of control over things such as alpha, scale or color and you can completely hide/show the addon with a single function call. You might even parent that container frame to another container and get yet another layer of control. Simply spoken: Smart use of container frames gives you a hell of a lot more control in terms of look and feel for you addon.
To give you an example why this approach works well: Take a look at the addon "baggins". Baggins creates a dynamic array of "bag" frames based on the user's configuration. The addon is written in a way so that each of these frames is a child of UIParent. Let's say I would want to go in and set a global alpha value for all of the bags programatically. This would be a hassle because I would have to adjust each bag frame individually. Since the amount of bag frames is dynamic, this would become a bit complicated quite quickly.
If all of Baggin's bag frames would be children of their own parent, let's call it "BagginsParentFrame", I would have it much more easy. Simple function calls on the BagginsParentFrame would give me all the control I need. With just a few lines of code I could create a global look and feel for the addon wihtout much hassle.
So if you're thinking about, or are in the process of writing an addon, please consider creating your own parent frame for your addon instead of using UIParent.
I'm looking for more general syntax suggestions rather than necessarily specific tags people want.
IMHO you should move the entire syntax close to either Java or ActionScript. Generally take a more object oriented approach and get rid of all the brackets everywhere.
Is it just me, or is the Baggins Skin no longer working?
edit:
Same goes for Quartz and Omen. Skinner gives the "XY loaded but skin not found in SkinMe directory". I reinstalled the addon and copied them over again just to make sure everything is up to date. Using r78577.
tango: ill look to see about making border layer adjustable
just got back from vacation so beqr with me ive gota read some of these threads over
That's cool. Thank you.
This is also basically the only thing I can find on your addon that doesn't work the way I'd expect it to. You did a great piece of work right there, man.
Can you look at the Buffalo2 and Chatframe skinning routines please? Or at least tell whether I'm the only one with that problem? Skinners renders both these components useless as it draws the skin over the addon. Having the Chatframe skinned is cool, not being able the see the chat anymore isn't.
im using the normal blizzard border setup nothing special for any new draw layer. I see where you are going and can only suggest making to panels 1 without a border and 1 with just the border and no background, and ue the level setting to move border ontop of the other.
Yeah that's what I'm doing right now. It's really a hassle, though. You have to create twice as many panels as you actually need, hence using twice as much memory. Any change on one of them means re-adjusting 2 panels instead of one. It's... coumbersome.
Tango2k7: try adjusting the panel insets instead of defaults with your rounded corners.
Fitting it this way is geometrically impossible. It will either leave you with a gap between border and background, or with the inner corners of the borders being clipped by the background as I described. More simple spoken: You can't fit a rectangle in a rounded rectangle.
It wouldn't be a problem if the borders would draw on top of the background.
Of course. My post was more directed at him, although partly in response to yours. You get the drift ;)
Quote from Phanx »
And "properly" is a matter of opinion, as I feel that my actionbars work just fine with Alt as my self-cast modifier. If you want to distribute a compilation, either adjust it to work with the default modifier, or write your own code to allow people to change it without having to *gasp* use slash commands.
I can also just ask the author to add the option for me :) In my setup Alt pages to a different set of bars entirely. Same goes for Shift/Ctrl.
Quote from Phanx »
The self-cast modifier function is not controlled or altered in any way by InfiniBar, so it's not really InfiniBar's job to change it.
The only thing selfcast can possibly interact with is actions and their buttons/bars. IB2 is an actionbar addon. So naturally selfcast and the option to deal with it should be included, as is the case on pretty much every other actionbar addon out there. It's also already present in IB2 with the "right click self cast" option. So why not wrap it up and add an option to change the key? No hard feelings here, just sayin'.
The self-cast modifier function is not controlled or altered in any way by InfiniBar, so it's not really InfiniBar's job to change it. However, you can easily change it yourself using some basic WoW API functions and the /run (or /script) command.
To see your current self-cast modifier:
/run ChatFrame1:AddMessage("Current self-cast modifier: "..GetActionSelfCastKey())
To set your self-cast modifier:
/run SetActionSelfCastKey("ALT")
or
/run SetActionSelfCastKey("CTRL")
or
/run SetActionSelfCastKey("SHIFT")
I know. I know :)
Do it anyway. Please?
My UI is used by several people and I really don't want them to have to fiddle around with API-calls and macros just to get the actionbars working properly.
Is moving Pet bar buttons around supposed to work? I get this:
..\AddOns\InfiniBar-2.0\IB_ButtonTypes.lua line 1265:
Usage: PickupPetAction(index)
Same here.
Also, please, pretty PLEASE add and option to change or remove the self cast modifier so I can use Alt-key to page bars. Without that function this beast of an addon is useless to me :)
I noticed that on any panel the colored background is actually drawn on top of it's border. Can you change the drawing routine so that the border remains on top of a panel? The way it is now it's impossible to set up a textured panel with rounded borders and color the background, because the colored rectangle will draw over the border, which looks pretty crappy. I don't have much time right now, sorry, but if you need them I can provide some screenshots to illustrate what I mean in a day or two. I hope my explanation is clear enough, though.
Oh and of course, great addon! I got my textures set up in minutes. Much more solid than eePanels2.
0
It's simple. Doesn't require any extra work.
0
Since I spend quite a bit of time designing and coding interfaces (although not in LUA but in AS3 and Java), one pretty major mistake keeps popping into my view again and again as I try out and configure ace addons. As you can probably tell from the topic: I'm talking about parenting the UIParent.
To be a little bit more precise: I think it is very bad practise when you use the UIParent object as a parent for frames your addons are working with. What you should be doing, imho, is create a parent frame that contains all of you addon's created frames as children. That "container" would then be a child of UIParent.
Why is this useful? Well it simply gives you as an author, the user, and people who might be doing modifications to your addon (maybe as part of a UI-compilation) a lot more control over the appearance of your addon. You get an additional layer of control over things such as alpha, scale or color and you can completely hide/show the addon with a single function call. You might even parent that container frame to another container and get yet another layer of control. Simply spoken: Smart use of container frames gives you a hell of a lot more control in terms of look and feel for you addon.
To give you an example why this approach works well: Take a look at the addon "baggins". Baggins creates a dynamic array of "bag" frames based on the user's configuration. The addon is written in a way so that each of these frames is a child of UIParent. Let's say I would want to go in and set a global alpha value for all of the bags programatically. This would be a hassle because I would have to adjust each bag frame individually. Since the amount of bag frames is dynamic, this would become a bit complicated quite quickly.
If all of Baggin's bag frames would be children of their own parent, let's call it "BagginsParentFrame", I would have it much more easy. Simple function calls on the BagginsParentFrame would give me all the control I need. With just a few lines of code I could create a global look and feel for the addon wihtout much hassle.
So if you're thinking about, or are in the process of writing an addon, please consider creating your own parent frame for your addon instead of using UIParent.
0
IMHO you should move the entire syntax close to either Java or ActionScript. Generally take a more object oriented approach and get rid of all the brackets everywhere.
0
Dude... you're like the Roadrunner. Bug chasin' you like the Coyote while you go *meep meeeep* *wooooooooosh*
0
edit:
Same goes for Quartz and Omen. Skinner gives the "XY loaded but skin not found in SkinMe directory". I reinstalled the addon and copied them over again just to make sure everything is up to date. Using r78577.
0
Fantastic! Thank you!
0
Sure.
Wait a minute, I'll zip them up and upload them to my server.
edit:
attached them to the post
0
That's cool. Thank you.
This is also basically the only thing I can find on your addon that doesn't work the way I'd expect it to. You did a great piece of work right there, man.
0
0
Yeah that's what I'm doing right now. It's really a hassle, though. You have to create twice as many panels as you actually need, hence using twice as much memory. Any change on one of them means re-adjusting 2 panels instead of one. It's... coumbersome.
0
Fitting it this way is geometrically impossible. It will either leave you with a gap between border and background, or with the inner corners of the borders being clipped by the background as I described. More simple spoken: You can't fit a rectangle in a rounded rectangle.
It wouldn't be a problem if the borders would draw on top of the background.
0
Of course. My post was more directed at him, although partly in response to yours. You get the drift ;)
I can also just ask the author to add the option for me :) In my setup Alt pages to a different set of bars entirely. Same goes for Shift/Ctrl.
The only thing selfcast can possibly interact with is actions and their buttons/bars. IB2 is an actionbar addon. So naturally selfcast and the option to deal with it should be included, as is the case on pretty much every other actionbar addon out there. It's also already present in IB2 with the "right click self cast" option. So why not wrap it up and add an option to change the key? No hard feelings here, just sayin'.
0
I know. I know :)
Do it anyway. Please?
My UI is used by several people and I really don't want them to have to fiddle around with API-calls and macros just to get the actionbars working properly.
So here's another PLEASE with sugar on top ;)
0
Same here.
Also, please, pretty PLEASE add and option to change or remove the self cast modifier so I can use Alt-key to page bars. Without that function this beast of an addon is useless to me :)
0
I noticed that on any panel the colored background is actually drawn on top of it's border. Can you change the drawing routine so that the border remains on top of a panel? The way it is now it's impossible to set up a textured panel with rounded borders and color the background, because the colored rectangle will draw over the border, which looks pretty crappy. I don't have much time right now, sorry, but if you need them I can provide some screenshots to illustrate what I mean in a day or two. I hope my explanation is clear enough, though.
Oh and of course, great addon! I got my textures set up in minutes. Much more solid than eePanels2.