Currently, the buttons are shared across all the unit frames in a given group, so they cannot be shown for all members of a party (for example).
Supporting the buttons being visible at the same time for all members of your party/raid is a matter of (1) available resources, and (2) screen space.
There are more frames to create when the buttons need to be shown for every member of the party, so the resources could grow dramatically for this configuration (especially in raids). It also affects fps rates, as the more buttons there are to update, the longer it takes to update them (again, gets worse in raids).
As for screen space, showing the buttons for the party members is one thing. You normally have space between each unit frame where the buttons could be shown. For raid groups, it becomes more of an issue, as you have 10, 15, 20, 25, 40 potential unit frames that need the buttons shown.
These are the issues that are making this not as high of a priority to address at this time. Not that I won't address it, but rather the reasoning as to why it hasn't been an issue to take care of to this point.
this is a really great mod, as a disabled wow player, this mod helps bring back functionality I lost in wow 2.0 THANK YOU!
I hate to add to the pile of requests, but is there anyway you could add support for perl classic unitframes? I know there is a lot of different raid frames out there so adding support to all of this is daunting/not possible. I have no problem using clique with perl unitframes, perhaps whatever hook clique uses UnitActionBars could also? Thank you again for a awesome addon.
Yep, I'll post a Perl Classic plug-in later today. Thanks for the support :)
Sorry it took a bit longer than I expected to get it posted. There is a new plug-in to provide UAB support for Perl Classic frames: uab_PerlClassicFrames.
Is Perl Classic the only unit frame add-on you have loaded? I can fix the specific problem relatively easily, but that error is caused by a frame with no name, which I haven't found anywhere in the Perl Classic code, or the code for other unit frame mods that uab supports at this time.
I'll keep looking to see if I can find any other cause for it.
Yes. Sorry. I should of elaborated. The error doesn't seem connected to perl or the perl uab addon, I get that error with pearl and agUF. I thought orginally that it was a perl bug, so I disabled that and used agUF. But got the same error. Hope this helps. Thanks!
In this case, I think the best option would be to skip parsing any frames without a proper name.
It would be pretty easy to skip un-named frames, but the end-result would be a silent failure. UAB doesn't work for those frames, but you get no indicator that it could not match the frame to any frame group.
For the most part, this is probably fine. I'll make this change later today.
The other alternative, would be to provide "default" support for frames that don't match with any frame group. These frames would follow the default layout settings and positioning settings. This would enable uab in a default mode for add-ons that are not explicitly supported with a uab frame group plug-in.
It would be pretty easy to skip un-named frames, but the end-result would be a silent failure. UAB doesn't work for those frames, but you get no indicator that it could not match the frame to any frame group.
So it wouldn't be possible to present the user with a dialog explaining that they have a unit frame addon installed that isn't compatible with UAB, and that the user should ask the author of the offending addon to fix the code?
Oh, and before I forget, the TOC file tries to load libs\AceModuleCore-2.0\AceModuleCore-2.0.lua, but that file isn't included in the ZIP (i.e. not listed as an external). It's not an issue for me since I manage dependencies manually, but one of my guild-mates ran into this.
So it wouldn't be possible to present the user with a dialog explaining that they have a unit frame addon installed that isn't compatible with UAB, and that the user should ask the author of the offending addon to fix the code?
Possible? yeah, I'm sure it would be. Desirable? maybe, maybe not. A message in the chat window might be less intrusive, yet still get the point across. In many cases, it doesn't work with UAB because UAB doesn't have a plug-in for that add-on, not because that add-on is doing something wrong. If the add-on didn't register with ClickCastFrames, UAB would not even know about it, and then it would be an issue for the add-on, since very few click-casting mods would work with it. UAB, however, currently limits support to add-ons that it knows about (i.e., there is a UAB FrameGroup that matches the frames created by that add-on). What I'm suggesting is that this restriction be relaxed so that if there is a frame that registers with ClickCastFrames, but UAB has no FrameGroup for it, UAB will support it with the default settings, but also give a message in the chat window about UAB not providing full configuration support for that frame.
Quote from kccricket »
Oh, and before I forget, the TOC file tries to load libs\AceModuleCore-2.0\AceModuleCore-2.0.lua, but that file isn't included in the ZIP (i.e. not listed as an external). It's not an issue for me since I manage dependencies manually, but one of my guild-mates ran into this.
Yeah, I got an e-mail about this one. I'm going to update the svn later today to fix this.
Possible? yeah, I'm sure it would be. Desirable? maybe, maybe not. A message in the chat window might be less intrusive, yet still get the point across. In many cases, it doesn't work with UAB because UAB doesn't have a plug-in for that add-on, not because that add-on is doing something wrong. If the add-on didn't register with ClickCastFrames, UAB would not even know about it, and then it would be an issue for the add-on, since very few click-casting mods would work with it. UAB, however, currently limits support to add-ons that it knows about (i.e., there is a UAB FrameGroup that matches the frames created by that add-on). What I'm suggesting is that this restriction be relaxed so that if there is a frame that registers with ClickCastFrames, but UAB has no FrameGroup for it, UAB will support it with the default settings, but also give a message in the chat window about UAB not providing full configuration support for that frame.
Oh, I see. I had made the assumption that UAB would be unable to support any Unit Frames that didn't have proper names, having no way to reference them. If this is an incorrect assumption, then I feel silent failure is a better option without any default fallbacks. If a user wants to use UAB with a particular unit frame, they should get the support addon for it. Then again, this could create a burden on you, having to update each support addon with each new unit frame addon or addon update.
The kind of issue that I forsee happening with "default support.":
Lets say that I'm using ArcHUD, and I don't have a UAB addon to support it since I don't feel I have a use for it. I have a UAB action set up to use the MiddleButton on agUF. I also have the MiddleButton set up to do something like "assist," assuming I'm not on an agUF frame. I'm in the middle of combat and I see a party member needs help. I select him and click the middle button somewhere near the middle of the screen. Whoops, it just so happens that I was hovering over the ArcHUD frame when I clicked. Now, instead of assisting, the UAB action frame has popped up and is in the way.
Yep. If you want the middle button to have no effect unless it is over a frame that you have UAB enabled for, then default support would not be good.
How about this?
1) If a UAB plug-in for a set of unit frames is loaded, but disabled, then frames for that add-on get no UAB support (not even default).
2) Provide a "Default support for unknown unit frames" setting
3) If there is no UAB plug-in for a set of unit frames, then the "enable default unit frame support" setting would determine whether to provide default UAB support for those frames.
This would enable you to avoid the problem with the scenario you described (by turning off the "Default support" setting), but allow someone else, who wants default support, to get it. It also allows you to explicitly disable UAB support for a specific, known, set of unit frames.
That sounds wonderful. It's always nice to theoretically work out all the usability issues before implementing a feature (something I wish I did more often) :D
Yep. If you want the middle button to have no effect unless it is over a frame that you have UAB enabled for, then default support would not be good.
How about this?
1) If a UAB plug-in for a set of unit frames is loaded, but disabled, then frames for that add-on get no UAB support (not even default).
2) Provide a "Default support for unknown unit frames" setting
3) If there is no UAB plug-in for a set of unit frames, then the "enable default unit frame support" setting would determine whether to provide default UAB support for those frames.
This would enable you to avoid the problem with the scenario you described (by turning off the "Default support" setting), but allow someone else, who wants default support, to get it. It also allows you to explicitly disable UAB support for a specific, known, set of unit frames.
UAB has been updated. Various uab framegroup plug-ins have been updated as well. UAB version is r30979. The "default unit frame support" setting is in the top level "Frame Group" menu. It is off by default, which retains compatibility with the prior versions of UAB.
Currently, the buttons are shared across all the unit frames in a given group, so they cannot be shown for all members of a party (for example).
Supporting the buttons being visible at the same time for all members of your party/raid is a matter of (1) available resources, and (2) screen space.
There are more frames to create when the buttons need to be shown for every member of the party, so the resources could grow dramatically for this configuration (especially in raids). It also affects fps rates, as the more buttons there are to update, the longer it takes to update them (again, gets worse in raids).
As for screen space, showing the buttons for the party members is one thing. You normally have space between each unit frame where the buttons could be shown. For raid groups, it becomes more of an issue, as you have 10, 15, 20, 25, 40 potential unit frames that need the buttons shown.
These are the issues that are making this not as high of a priority to address at this time. Not that I won't address it, but rather the reasoning as to why it hasn't been an issue to take care of to this point.
Sorry it took a bit longer than I expected to get it posted. There is a new plug-in to provide UAB support for Perl Classic frames: uab_PerlClassicFrames.
Error: bad argument #1 to 'find' (string expected, got nil)
AddOn: UnitActionBars
File: FrameGroup.lua
Line: 295
Count: 1
Any ideas? Thanks for the help! =)
I'll keep looking to see if I can find any other cause for it.
I am receiving the same error without using any extra UnitActionBars AddOns. Just agUF.
It appears that ArcHUD does, indeed, create frames with nil names. For example, line 194 of ArcHUD2/Frames.lua:
local targethud = AH_CreateFrame("Frame", nil, main, {300, 100}, {"TOP", main, "BOTTOM", 0, -50}, nil)That first nil is where the name would go. I'll do some tests to see if I can add frame names myself, then perhaps submit a patch.
It would be pretty easy to skip un-named frames, but the end-result would be a silent failure. UAB doesn't work for those frames, but you get no indicator that it could not match the frame to any frame group.
For the most part, this is probably fine. I'll make this change later today.
The other alternative, would be to provide "default" support for frames that don't match with any frame group. These frames would follow the default layout settings and positioning settings. This would enable uab in a default mode for add-ons that are not explicitly supported with a uab frame group plug-in.
So it wouldn't be possible to present the user with a dialog explaining that they have a unit frame addon installed that isn't compatible with UAB, and that the user should ask the author of the offending addon to fix the code?
Oh, and before I forget, the TOC file tries to load libs\AceModuleCore-2.0\AceModuleCore-2.0.lua, but that file isn't included in the ZIP (i.e. not listed as an external). It's not an issue for me since I manage dependencies manually, but one of my guild-mates ran into this.
Possible? yeah, I'm sure it would be. Desirable? maybe, maybe not. A message in the chat window might be less intrusive, yet still get the point across. In many cases, it doesn't work with UAB because UAB doesn't have a plug-in for that add-on, not because that add-on is doing something wrong. If the add-on didn't register with ClickCastFrames, UAB would not even know about it, and then it would be an issue for the add-on, since very few click-casting mods would work with it. UAB, however, currently limits support to add-ons that it knows about (i.e., there is a UAB FrameGroup that matches the frames created by that add-on). What I'm suggesting is that this restriction be relaxed so that if there is a frame that registers with ClickCastFrames, but UAB has no FrameGroup for it, UAB will support it with the default settings, but also give a message in the chat window about UAB not providing full configuration support for that frame.
Yeah, I got an e-mail about this one. I'm going to update the svn later today to fix this.
Oh, I see. I had made the assumption that UAB would be unable to support any Unit Frames that didn't have proper names, having no way to reference them. If this is an incorrect assumption, then I feel silent failure is a better option without any default fallbacks. If a user wants to use UAB with a particular unit frame, they should get the support addon for it. Then again, this could create a burden on you, having to update each support addon with each new unit frame addon or addon update.
The kind of issue that I forsee happening with "default support.":
Lets say that I'm using ArcHUD, and I don't have a UAB addon to support it since I don't feel I have a use for it. I have a UAB action set up to use the MiddleButton on agUF. I also have the MiddleButton set up to do something like "assist," assuming I'm not on an agUF frame. I'm in the middle of combat and I see a party member needs help. I select him and click the middle button somewhere near the middle of the screen. Whoops, it just so happens that I was hovering over the ArcHUD frame when I clicked. Now, instead of assisting, the UAB action frame has popped up and is in the way.
Is that a reasonable scenario?
How about this?
1) If a UAB plug-in for a set of unit frames is loaded, but disabled, then frames for that add-on get no UAB support (not even default).
2) Provide a "Default support for unknown unit frames" setting
3) If there is no UAB plug-in for a set of unit frames, then the "enable default unit frame support" setting would determine whether to provide default UAB support for those frames.
This would enable you to avoid the problem with the scenario you described (by turning off the "Default support" setting), but allow someone else, who wants default support, to get it. It also allows you to explicitly disable UAB support for a specific, known, set of unit frames.
UAB has been updated. Various uab framegroup plug-ins have been updated as well. UAB version is r30979. The "default unit frame support" setting is in the top level "Frame Group" menu. It is off by default, which retains compatibility with the prior versions of UAB.
Main.lua:lines 213 and 494 both use uab.profile.db instead of uab.db.profile.