TODO list for Grid! -*- mode: outline; fill-column: 79 -*- * Introduction If you guys can come up with a better way of keeping track of this information, I'm open to suggestions. I just don't want to rely on IRC logs and my memory for keeping track of what needs to be done on Grid. Right now, I'm using emacs's outline mode so I can expand/collapse headings. The line above this paragraph is what tells emacs the settings I want for this file. Let me know if SciTE and TextMate support the emacs outline mode or if there is a way to let them fold regions in files that aren't code. The todo items below should probably get categorized by bug / new functionality / change in existing functionality and then by module. -Pastamancer * Create global status registry ** Description GridFrame has no way of knowing what categories/statuses are available and therefore cannot create a menu to assign those statuses to indicators. A status registry would allow any GridModule to see what statuses have been registered by GridStatus modules. ** Discussion *** Pastamancer 2006/10/18 In r45 I added GridStatus:RegisteredStatusIterator() and GridStatus:IsStatusRegistered(category, status). *** Pastamancer 2006/10/20 Done. * Allow modules to be enable/disabled ** Description Modules aren't enabled/disabled, they are just there - which is why Grid can't be put on standby mode yet (or at least it won't hide anything even though I added some code to GridLayout:OnDisable(), which doesn't seem to be called from anywhere) ** Discussion *** Pastamancer 2006/10/16 I definitely want to get this done, but it's lower on my priority list than most of the other things that need to be done. If I get a chance, I'll take a look at how BigWigs handles it and see how much time it would take *** Pastamancer 2006/10/18 In r45 I actually started calling :ToggleModuleActive(). It shouldn't be too much more work to add a command to disable a module. * Reduce configuration menu clutter ** Description config UI issue: how do we get rid of these additional subfolders for modules? most module will only have one setting, and even if they have two, it might make more sense to have them feed the parent table with these options? ** Discussion *** Maia 2006/10/18 I guess we have two options (which we could probably even use both): option a) display status modules in the first dropdown, instead of having them all inside a "GridStatus" submenu. option b) instead of creating a submenu per status module and then subsubmenus for each status category the module registers, merge them all into one menu. this menu could have a header for each module, with the status categories below. *** Pastamancer 2006/10/18 I'll take option a. If we stick a separator or blank spot in the menu and have all the status modules below it, that should be good. * Ensure indicators accurately reflect the state of the unit ** Description Find a way to keep updating the indicators as long as they are shown, as its possible that e.g. someone is in range and debuffed, but then moves out of range. we'd need to hide the indicator. ** Discussion *** Pastamancer 2006/10/16 I think this can be solved with modules updating on Grid_UnitCreated and with range being added to Grid_StatusGained. * Use frames for each column, inside these 8 frames 5 units each ** Description The TBC patch will introduce SecureRaidGroupHeader and SecurePartyGroupHeader (see FrameXML/SecureTemplates.lua) which is the only way to update units in combat. We should use this logic asap to have a seamless TBC transfer. ** Discussion *** Maia 2006/10/18 My suggestion is to have GridLayout create the group header frames and let them inherit SecureRaidGroupHeader even if that doesnt exist in 1.12 yet, as we can copy&paste the code from the TBC beta. We feed the header with the available configuration attributes (I wouldnt worry about using nameList but would currently only use groupFilter to either show subgroups or classes) and the xml template of our unit button. * Improved scaling ** Description As the scaling only creates nice results on 100% and 200% due to scaling 1px borders without antialising them, we could alter the frame width/height, border width and indicator size instead. ** Discussion *** Maia 2006/10/18 I recommend to wait until we're using the SecureRaidGroupHeader and have access to TBC to be able to check what can be done in combat. If both of you think the current box size of 20x20px is too small, I suggest we simply increase it to 22/22 or 24/24 as new default. * reactive modules ** Description Allow status modules to only show information if a meta key is down. * TBC range check ** Description wow 2.0.0 will introduce result = IsSpellInRange(spell, unit) to check ranges. We currently let modules send a predefined distance, but should send a spell instead. ** Discussion *** Maia 2006/10/18 As each class has different spells, we should let the user define which spell they want to check for each module. I'd therefor expand the 'range check' toggle to a submenu with: a) a toggle "skip range checking" and b) a text input box people can use to enter their spell. If the spell is invalid or nil, we use UnitIsVisible() as fallback. And pre-TBC instead of checking for that spell we internally continue to use the 40yrd check. *** Pastamancer 2006/10/18 Do we know for sure that ProximityLib is going away in TBC? I'd much rather use numeric ranges and let something else decide what spell to use for the IsSpellInRange() check.