Continuing with this thread's original idea of Grid2 vs Grid, why is so much development focusing on classic Grid instead of the new(er) Grid2? There aren't many Ace addons where the original version thrives while the sequel stagnates (Cartographer 3 is was a notable exception).
What is the point of the bag priority sliders if the section priority sliders don't affect only the bag they're in?
Take the Fell Blossom for example. Given the following layout:
Bag: Trade Goods (priority 10)
Section: Herbs (priority 10)
Rule: PTSet->Tradeskill.Gather.Herbalism
Bag: Consumables (priority 15)
Section: Buffs (priority 5)
Rule: PTSet->Consumable.Buff
Technically, the Fel Blossom could go in either category. It is gathered using Herbalism, but it is also a consumable that gives you a buff. Logically, it should be placed in the Consumables category since it's not used in any tradeskill recipes. I would assume that since the Consumables bag has a higher priority than the Trade Goods bag, it would be placed in Consumables. Unfortunately, this is not true. Baggins seems to ignore the bag's priority and looks only at the section priorities, placing the Fel Blossom in the Herbs section of the Trade Goods bag. If I raise the Consumables->Buffs section priority to 11, the Fel Blossom moves to that section.
This seems like a problem to me. Or perhaps I just don't quite understand how the priorities are intended to work.
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "gui.py", line 185, in reload_data
except wowace.urllib.URLError, e:
AttributeError: 'module' object has no attribute 'urllib'
changing urllib to urllib2 on that line results in an error further down the code:
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "gui.py", line 190, in reload_data
except IOError, (errno, strerror):
ValueError: need more than 1 value to unpack
Despite the errors, the gui appears and is responsive. Clicking on the "World of Warcraft Addons directory" browse button throws:
Traceback (most recent call last):
File "gui.py", line 290, in browse_wowdir
dlg = wx.DirDialog(self, "Choose your WoW Addons directory:", style=wx.DD_DEFAULT_STYLE | wx.DD_DIR_MUST_EXIST)
AttributeError: 'module' object has no attribute 'DD_DIR_MUST_EXIST'
After entering my AddOns directory manually, the addons show in the Install tab, but there is no scroll bar on the list. Paging up and down using the keyboard works fine. To top it all off, the window has no decorations (title bar, close/minimize/maximize buttons, etc). Other than that, excellent utility! I've been using the command line up to this point since I just now realized it had a gui.
I'm using Python 2.4.4 (#1, May 26 2007, 08:28:55) with wxPython/wxGTK 2.6.3.3.
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
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.
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.
If you run any of the other uab action sets, or bring up the buttons on any visible frame, does the close button in the middle of the screen go away?
Nope. I had started over again and only had the "Heal" set available. I added a new set, "Test". Running the "Test" or "Heal" sets doesn't get rid of the close button, even if I run in on the ToTT frame. After a UI reload the rogue close button is identified as "TesttargettargettargetActionBtnNone". I can only assume that the "HealtargettargettargetActionBtnNone" frame is underneath it (perhaps there's a whole stack that I just can't see).
I's all fixed now. I must say, you rock. UAB support for ArcHUD is certainly not something I'd considered before, and is personally not something I'd use, just so you know. :-D
Edit: Whoops, spoke too soon. After relogging, the UABs work correctly (instead of not showing up), but there is now a persistent close button in the middle of the screen that won't go away when I click on it.
Edit Again: A /dump GetMouseFocus() reveals the name of the frame as HealtargettargettargetActionBtnNone. I happen to have agUF's ToTT frame hidden, but enabling it (and reloading) doesn't do anything.
0
Continuing with this thread's original idea of Grid2 vs Grid, why is so much development focusing on classic Grid instead of the new(er) Grid2? There aren't many Ace addons where the original version thrives while the sequel stagnates (Cartographer 3
iswas a notable exception).0
0
0
0
(removed because I can read)
0
Take the Fell Blossom for example. Given the following layout:
Technically, the Fel Blossom could go in either category. It is gathered using Herbalism, but it is also a consumable that gives you a buff. Logically, it should be placed in the Consumables category since it's not used in any tradeskill recipes. I would assume that since the Consumables bag has a higher priority than the Trade Goods bag, it would be placed in Consumables. Unfortunately, this is not true. Baggins seems to ignore the bag's priority and looks only at the section priorities, placing the Fel Blossom in the Herbs section of the Trade Goods bag. If I raise the Consumables->Buffs section priority to 11, the Fel Blossom moves to that section.
This seems like a problem to me. Or perhaps I just don't quite understand how the priorities are intended to work.
0
Running gui.py results in an error:
changing urllib to urllib2 on that line results in an error further down the code:
Despite the errors, the gui appears and is responsive. Clicking on the "World of Warcraft Addons directory" browse button throws:
After entering my AddOns directory manually, the addons show in the Install tab, but there is no scroll bar on the list. Paging up and down using the keyboard works fine. To top it all off, the window has no decorations (title bar, close/minimize/maximize buttons, etc). Other than that, excellent utility! I've been using the command line up to this point since I just now realized it had a gui.
I'm using Python 2.4.4 (#1, May 26 2007, 08:28:55) with wxPython/wxGTK 2.6.3.3.
0
0
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?
0
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.
0
0
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.
0
I am receiving the same error without using any extra UnitActionBars AddOns. Just agUF.
0
Nope. I had started over again and only had the "Heal" set available. I added a new set, "Test". Running the "Test" or "Heal" sets doesn't get rid of the close button, even if I run in on the ToTT frame. After a UI reload the rogue close button is identified as "TesttargettargettargetActionBtnNone". I can only assume that the "HealtargettargettargetActionBtnNone" frame is underneath it (perhaps there's a whole stack that I just can't see).
I've attached an updated savedvars file.
0
Edit: Whoops, spoke too soon. After relogging, the UABs work correctly (instead of not showing up), but there is now a persistent close button in the middle of the screen that won't go away when I click on it.
Edit Again: A /dump GetMouseFocus() reveals the name of the frame as HealtargettargettargetActionBtnNone. I happen to have agUF's ToTT frame hidden, but enabling it (and reloading) doesn't do anything.