Originally Posted by Brem
1. Unit Frames - Mazzle uses DUF which has been (at least partially) updated. The 3D figures are custom Mazzle.
|
I think we're going to have to figure out the 3D figures (Mazzle might help?). They're the 'eye candy' that attracted me to Mazzle in the first place.
As for DUF...maybe we should examine creating our own Frame library; IMHO, I don't want to have to rely on another add-on for core functionality (because, let's be honest, projects do die).
Originally Posted by Brem
2. HUD & Context Menu - Both of these were custom developed. It appears that the HUD relies on some combination of Discord Art/Unit Frames. Context menu is custom Mazzle.
|
Same as above; DUF is nice, but this is core functionality here and I think we might be wise to steer clear.
Of course, we can make the HUD non-core by including another add-on...depends on if we want to say the HUD is 'necessary'.
Originally Posted by Brem
3. Action Bar - To make the thing look right, I think these have to (at least) be placed. Adding spells would also be nice. (A feature request might be to be able to submit user supplied button layouts)
|
Another core functionality. I like the user supplied button layouts (although, really, users can add their own if they understand the Mazzle code)...maybe set this up to be 'skinnable' (XML file or something?).
I'd also like to work in the functionality that user placed button changes are kept from one mazzifier to another (I loved the mazzifier, hated that I kept having to set up my macros and mounts).
Originally Posted by Brem
4. Minimap & Button shuffling - Mazzle was great about removing unnecessary buttons from the minimap and putting them either on a FuBar or custom placing them if there was no FuBar option
5. Mazzifier - This is a gigantic piece of custom code that allows the "base" units to be laid out and configured. This is probably the real work here.
6. Skinning & Efficiency - Skinning the bottom panel is critical (I think) to Mazzle. I'm not so sure about effiiciency modes, I never used them and don't know how crucial they are.
7. Non-core mods - Being able to place "non-core" mods that are still useful is important, but less so.
8. Intelligent enabling of mods - Knowing what class & tradeskills and setting up special mods & buttons. Sure, include class-specific addons (pallypower, shard ace, totem timers, what have you) but turn them off for those classes that don't use them.
That's my input. What do we think?
|
I *think* it's possible to get some abstraction here. In terms of designing the components, I'd like to see a multi-tier thing (especially if we have to depend on other mods for core functionality). For example, we fix/rewrite/etc. the Mazzle ui to call specific functions held in the 'middle-ware' and the 'middle-ware' translates the calls into whatever base add-ons and Warcraft APIs we use. That way, from patch to patch, we only have to change things in the 'middle-ware' layer; so, if an API changes from fubar( a, b) to fubar(b,a) or fubar(a,b,c) we only have to work in the middle-ware to fix it. Also, abstracting the other add-ons gives us the same opportunity.
I'd also like to see enough comments in the code that if a whole new team takes over for the next patch, they're not left scratching their heads wondering what the heck we were thinking.
Personally, I'm not so worried about code theft -- that's how I learned most of C, by searching through other people's code file to see how they did it. I think this qualifies as a hobby (or perhaps an insane love affair) rather than a product -- so who cares if they rip off chunks of code?