I've put up the first beta of Bagnon 2.0. First up, here's what I've yet to do: 
* Frame strata options 
* Automatic display options 
* Slot coloring options 
* Some way to disable the individual frames 
* A way to lock your frame position 
* Profile management (I may revet to simple per character settings, anyway) 
* Refactoring 

So, if you care about any of those things, then the beta version is not for you. Otherwise, everything that's implemented should be stable. What I want people to do with this version is to basically rip it apart: Break and bitch about anything you can, so that I can fix any annoyances.

So I'm working on a 2.0 version of Bagnon:

Mainly, this version is me simply trying out a different style of writing code, with a heavy reliance on passing messages between all of the interface components. Because of that, the version you're looking at may never reach the release stage. Though it uses a huge amount of memory right now (I probably need to replace callback handler with my own thing), it allows me to do some interesting things.

This version is also for me to try out a lot of changes to the overall interface I've wanted to make:

• The first thing you'll probably note is that the inventory frame and keys are split. To be honest, I doubt they should have ever been part of the same frame :P
• Empty item slots now have a background. This is basically just to see how it would look, especially when I implement specialty bag coloring.
• The bag frame now has a new toggle button. This is mainly for space saving and usability purposes.
• The bag frame is at the top of the frame. Bags have an indicator that tells if you if they are visible or not. Hopefully this will prevent the "my items have disappeared!" problem.
• The search frame now has a toggle button. Again, this is to make things more obvious.
• Searching for items now uses the Combuctor search syntax.
• Added a carousel like libdatabroker display on the bottom right. This seems the simplest way to solve the "I want a bank stack button, I want a currency tracker, I want a bag space tracker" problem.

There's still a good bit of work to go (there's no saved settings in this version, for example), but I think its shaping up decently :P 

I'd love to hear people's thoughts on the layout, etc.

So random thoughts:

My guild has become _much_ more active since Wrath hit and everyone made it to 80.  10 man Naxx has ben fought many a times.  This, along with the real world have been the main factors as to why I've been doing a lot less coding as of late.

Anyway, you know the drill:  Here's what I'm planning on doing in the future.

Sage:

I'm using it as my primary set of unitframes now, and the svn version is fairly usable.  There's still a few kinks, but I hope to have a new version out by Feb.

Dominos:
Besides super ultimate integration with dual specs once 3.1 hits, the main thing I want to do in Dominos is better vehicle/possess bar support.  I want to bring back the option to use the pet bar as the possess bar, or at least emulate that functionality.

Beyond that, I still have this dream scenario for an actionbar addon in my mind:  You define complete layouts based on what state you're in ("I'm in a vehicle -> show only the vehicle bar, etc, at this location & use these bindings", "I'm in cat form, do this").  This, of course, would be a completely new addon.  I probably won't ever implement it, unless blizzard gets around to making nice spell button.  Either way someone should implement it at some point in time :P

OmniCC:

The main thing you're going to see here is a bit of tweaking.  10ths of a second may become a display option (ideally, i want to give users full control over the text formatting options, if I can).  I'm planning on splitting out the pulse option of OmniCC, and hopefully making it easy for people to implement the classic shine.

Combuctor/Bagnon:

Yep, lumping these together.  For Combuctor, I want to write the new set API, and document the hell out of it.  After that, I'll probably work on adding a few configuration options.  For Bagnon, total rewrite.  The code is getting a bit crufty, and I just want to solidify the design.  The ultimate dream here:  To merge as much of Bagnon and Combuctor's code as possible (without introducing bloat, of course).

Ludwig:

Also planning a rewrite of the GUI.  The goal here is just more to clean up/modernize the code than anything.

SellFish:

Zero planned, other than the scheduled database updates.

So yes, whenever I get a beta key, I'll be doing the following:

Playing the game a bit mod free. The goal being here to see how all of the new ui features are supposed to work. More specifically, I'll be playing a death knight a good bit to learn about how runes are displayed etc.

After that, I'll be updating my addons, one by one. Here's what to expect:

Bongos

Will be reaching end of life status. It will not be updated for Wrath.

Dominos

Will be updated to Dominos 2.0.x to signify Wrath compatibility. Beyond the obvious things like support for the Death Knight class, I expect to add in a one bag option (may be pre wrath depending on how long it takes for me to get a key), and to hopefully fix the "You need to bind your keys for stances to work" issue. Unless something absolutely drastic happens, your settings will not be reset.

Bagnon

Will be updated for Wrath compatibility. Main thing I plan on doing is a major code review (again).

Combuctor

Fate is up in the air at the moment. There's a good bit of UI issues I need to rectify before I can move further on the project.

OmniCC

Will be updated for Wrath compatibility. Thinking about adding a per character settings option, along with the return of the flash. The big issue I want to fix is to make the pulse option not kill FPS, but that might not be feasible.

Sage

Will be updated for wrath compatibility. Sage 3.0 will be a major revamp, at least on the backend. Shared Media 3.0 will be supported.

Sellfish

Will be updated. Nothing new will be added (its in support mode, obviously).

Ludwig

Will be updated. Will likely look at doing a code review, along with support for spells and trade skills.

So one day, I came to the following conclusions:

• I'm not the target audience for Bongos3. A 10 bars, 12 button each setup just feels better in my head.
• ButtonFacade, StickyFrames, and LibKeyBound now exist. I should see how much I can do with them.
• It looks like the stock action button code is at a point where I can use it. I should see how much I can do with the code, especially since I have less time to code now than before due to work/social life/etc.
• I've had the idea of writing a Bongos2.5 in my head for a while: Bongos2, but with some of the tricks I've learned from writing Bongos3.

And with those things in mind, I wrote Dominos, and I'm really happy with the results. Its actually an entertaining project to work on due to my restriction of maintaining as much compatibility with the stock action buttons as possible.

Its not all fun, though. I'm effectively abandoning Bongos3. If someone wants to take up the reigns on the project they can. If I ever come back to it, it will be to rewrite the thing as an infinite action button addon. Its what I really intended the thing to be.

So far, no one has really yelled at me for doing this, which I'm a bit surprised about. I think people will, once they realize what has happened on the first patch day that Bongos3 really breaks. Who knows, that might not happen until Wrath.

Bongos3 has been out for a week or so now, and so far has been relatively bug free.

Bongos3 is not perfect. Not every single setup that was possible in Bongos2 is possible with Bongos3, since I've added a restriction that prevents buttons from being repeated between bars. For me, this is not a game breaker, but I'm sure it is for others. Its honestly something I should have anticipated, and I'd love to hear about examples of where this is truly a gamebreaker for people.

Its not easy with Bongos3 to keep some sort of parity with the stock actionbar interface, and I really have no intention on making it easy I found, that even with Bongos2, it was difficult for me to revert back to the stock actionbar interface.

These issues always make me think that I should have implemented Bongos3 as an infinite actionbar addon. That would resolve the mirroring issue by allowing repeated buttons, and also the parity issue via allowing one to use Bongos3 only as a supplement. Bongos3 actually started out with the intent of being an infinite action bar addon, but I found a showstopper along the way that prevented me from implementing it as one.

Hrm, this probably makes me sound like I dislike 3. That's not the case :) I'm actually quite happy with it, but frustrated that I cannot satisfy everyone :P

Sage is likely next on my list of addons to update. Also, Iron Man is awesome.

Yeah, I've not posted in a good while. Here's the status on my stuff:

Bongos

I'm working on Bongos3 now. Most of you should know this due to the betas being out. The goal with Bongos3 is to do two things: Fix anything broken in Bongos2 that could not be done without redoing profiles, and to implement variable length bars.

To do the first, I've done the following:

• Stances are now done via [bonusbar:x] conditions. Druids lose the ability to have their bars change in say, travel form, but stances should all finally work out of the box, no matter what forms you know or do not know. It also fixes Shadowform on priests to not switch your bar if you're in Spirit of Redemption. I didn't actually intend on doing this, but it just happened that Blizzard added enough to the API to make it possible.

• Bindings for action buttons are now done via binding overrides. Basically, this means your action bar bindings now sit on top of your other bindings, and as a plus, are attached to profiles. This fixes a very common problem with Bongos2: "My bindings don't work when I switch to cat/stealth/berserker!"

• The possess bar is implemented. For people who have been using Bongos for a long time, the possess bar is a feature Blizzard added in 2.3 that switches your main bar when you well, possess something. You can see it in action if you do the kara chess, cast eyes of the beast, or in certain raid encounters.

• Bars are now created using a new painting system. Enter configuration mode, and alt drag on an empty space to start creating a bar. The biggest problem with this system is that you're still limited to 120 buttons overall, but I really do not think the API is quite ready for me to implement infinite action buttons.

The following two things were derived from me implementing variable length bars

• User defined show states. Its now possible to make a bar show only when a macro condition is true, like [combat]. The only thing I'm really using this for is to hide bars when possessing something, but I'm sure others users will come up with something for it.

• The action sets mechanism for configuring stances. In Bongos2, you'd say, "This bar should show the buttons on bar3 when in cat form, and bar2 when in bear form" Lets call this bar mirroring. Bongos2 could get away with bar mirroring, since every bar has the same effective size. Bongos3, however, does not have that limitation. So telling Bongos3 that you would want bar 1 to show the buttons on bar 2, when bar 2 is 1 button, and bar1 is 30, would not make very much sense. So instead, you tell Bongos3, "This bar should have this many sets of buttons. When I'm in cat form, use set 2, when I'm in bear form, use set 3, otherwise use set 1"

Issues

It sounds nice...but I'm not yet satisfied with the design. I need to add in more feedback to the bar creation/destruction and stance configuring stuff in Bongos3. It really does make sense, once you understand it, but getting to the point of understanding it is going to be too difficult for the average user.

The second issue I've been having is the binding system. The first implementation I wrote for Bongos3 did not work properly for non US locales. I released a new implementation yesterday, and if that does not work, then I'm probably headed toward writing a Bongos 2.5. The rest of Bongos3 cannot really work at this time unless the binding system works.

There are, of course, other minor issues, but I'm not thinking about them until I solve the major ones :)

Other Addons

Bagnon For now, Bagnon is in bugfix only mode. If someone wants to fork it to add in more features, then by all means do it.

Combuctor Combuctor's priority is lower than Bongos3. Odds are, it'll be released more or less as is, or I'll completely revamp it. Not sure which :P

Sage Sage is lower than Combuctor in priority. Again, its going to be a "minor changes" or "total revamp." I'm leaning towards the middle, somehow :P

OmniCC Bugfix mode, like Bagnon. There's really nothing else I want to implement that's not there.

SellFish & Ludwig Same :P

Starting this week, I'm going to have significantly less time to work on stuff. The good news, however, is that I typically only work in spurts anyway :)

I plan on releasing new versions of both Bagnon and Bongos by Monday. These will be primarily bug fix versions. Did you know that Bagnon Forever is currently broken? I do (now).

Combuctor... The inventory and bank frames feel a bit...off still. Items are sometimes a bit too small in the inventory frame, and I really don't need to see the side filters all of the time. Odds are, the side filter buttons will be able to be hidden because of this. The sizing problem is a bit more difficult of a task to handle, and my only real reason to revert to using Bagnon. It may require a frame redesign (dun dun dun). Other than that, however, I'm quite satisfied with Combuctor.

2.3 is this week. Most of my addons have been updated (I'm doing a bit more work on Bagnon tomorrow). Here's what you can expect:

Sage

The 2.3 release of Sage will be a point release. I've not added any new features, but I've fixed a profile copying bug and am now using IsHelpfulSpell and IsHarmfulSpell for far more accurate cast bar coloring. At some point in the future, Sage will be getting SharedMedia support, but that's the only thing I'm certain of for now. The release will be sometime Monday night.

SellFish

Another point release. You'll be getting updated sell value data, but other than that, nothing needed to be changed. You can grab it now, if you want to avoid the rush.

Ludwig

I've removed the /ludwig --scan command, since Blizzard reinstated disconnects for queries of items you have not seen. Additionally, Ludwig is now rocking the new 2.3 item categories.

Bagnon

Bagnon is getting a few bug fixes, since most of the changes I wanted to make were made a bit last month. Tooltips are planned to be put in a second addon, Bagnon_Tooltips, but I may go back on this. I'll be doing more work on the addon tomorrow/today.

Combuctor

Combuctor has had a few alpha releases, which you can grab on my google code page. Its pretty stable right now, but I'm still not quite sure what I want to do with it still. I do, however, want a release out before 2.4 :)

Bongos

Basically, you're getting a lot of bug fixes + a couple new features. The first new feature is the ability to bind keys directly to macros. I originally intended to have this in the 1.8 version, but never got around to it :) The second new feature is FlexBar2 style buff and debuff highlighting. When enabled, any debuff you currently have on an enemy target will cause its corresponding action button to have a purple border. Buffs on friendly targets, or yourself will show up in green, and the same goes for items and macros. I like it quite a bit, and hope you all will, too :)

In the Year 3000....

In the near future, most development work is going to be done on Combuctor, followed by Bongos and Sage. The current goal is to attach action buttons and keybindings to Bongos profiles for the next major release. 2.4 is scheduled to be on the PTRs quite soon, and if that adds in anything nifty I might scrap the idea for now :)

Trinity Bars 2.0

Maul is working on Trinity Bars 2.0, which, beyond being a rewrite, will be featuring infinite action buttons. Now, this isn't the first time someone has done this (InfiniBar and FlexBar2 both have implementations), but it will be the first major action bar addon with the feature.

Patch 2.2

2.2 is now out, the first major patch in a long time. I'm a bit disappointed that there was no new content to go with it, but it seems that the turnaround between this patch and 2.3 will be quite quick. I'm really looking forward to ZA. I'm also looking forward to the Brewfest stuff hitting the retail realms, as well as VOIP. My guild will continue to use vent, but it'll provide a good bit of entertainment for me on pickup runs :)

Anyway, the arrival of a new WoW patch means that addons also have to be updated. The biggest single change to the interface is alteration of all tooltip functions to be easier to have managed updates. This is good news for me, since it means I don't have to write my own system for throttling tooltip updates (a decent source of performance loss). It also means a whole bunch of addons were broken by the change, but those issues will and are being resolved by updates.

Addon Updates

Bagnon has had a few significant issues related to 2.2. A lot of users are reporting tooltip errors, most of which are the result of them using tooltip modifying addons that have not been updated for the patch. A few errors were actually the fault of Bagnon, but I've squashed those issues now.

Bongos had an issue with the experience bar brought about by me rewriting it. I should have caught it in the testing process, but failed to do so. A good bit of users are also reacting negatively to the merging of the keyring and bag bars, since people seem to use the bag bar, but not the keyring. My plan right now is to simply make it possible to hide the keyring. Another issue has come up too: PickupAction was made secure, so its no longer possible to pick up actions in combat in the current implementation of Bongos ActionBar. I'm mulling over a major rewrite of the ActionBar portion to fix this.

Users are now discovering an issue in OmniCC: cooldowns are becoming hidden after opening the map. I plan on fixing this when I do a bit of a rewrite. I want to do two things in the rewrite: make the code less hacky, and also implement a configuration GUI.

SellFish has undergone a significant rewrite. I'm now using a sell value library called ItemPrice as the database back end. Its smaller and a bit faster than my old method of a big ass compressed string, and also means that I no longer have to worry about doing my own parsing of the armory :) I don't expect to make any major changes in the near future.

Sage and Ludwig have had no real issues since the patch. I'm not planning any major updates.

Combuctor will be worked on after I update OmniCC and Bongos. I've not done much work on it since I wrote this post, as I took a little bit of a break from addon coding.

The Great Forking

Ace2 was the first real embedded framework created for WoW, and is beginning to show its age. Ace2 is big, crufty, and even a bit buggy. So, developers have started the process of building a successor. Three major things have come out of this.

The first thing is LibStub. LibStub basically allows us to create embeddable libraries with minimal overhead. This is a significant thing for me, because it means I can finally think about using some of those nice libraries that are around. As mentioned earlier, SellFish was converted to use ItemPrice. This was the reason. I encourage all library authors to think about reworking their libraries to use LibStub.

The second thing is Rock, ckknight's new framework. Rock, from my standpoint is effectively a rewritten Ace2. I've not really done any benchmarks, but I know it has a smaller initial memory footprint than Ace2 by a significant amount. All of ck's addons have been converted to use Rock. I think ck was a bit too quick to get Rock out to users, since there were many bugs to quash. I'm sure it'll be much more stable over time, but a lot of users were put into the 'Rock sucks' mode because of the quick release.

The third thing is Ace3, a new framework being developed by a handful of developers in the Ace community. Ace3 is a completely different beast from Ace2. Each part is being designed to work independently to also be quite small. I'm watching this one closely, though it will not be out for a while.

Why are there multiple frameworks around? Because developers have different ideas :) Overall, it won't be a bad thing that multiple frameworks exist, as I expect most libraries to be converted to LibStub.

Infinite Action Buttons

One major change being implemented by 2.3 is the possibility of cleanly faking action buttons. This is important because it means its possible for us to break the 120 button limit. It also means that action button settings will need to be saved on your computer, which will make it a bit more difficult to transfer between computers.

Maul (TrinityBars) and Cogwheel (CogsBar) are both going to be working on implementations, and I think I heard that Maul is going to convert trinity to the system. I'm thinking about working on it myself, but more as a supplement to Bongos ActionBar, and not a replacement. It really depends on how well such a system would perform.

That's basically what combuctor looks like as of right now. Its still very much alpha at this point, and I might redesign the frame again after I start using it for a while. My main worry is that the frame is too cluttered.

Some notes:

• The item area of the frame dynamically scales to fit how many items are being displayed at once. Its a bit small when showing your entire bank, but I expect people to filter to find stuff.

• Those tabs on the bottom are dynamically generated based on what bag types you're carrying. If you have an ammo/shard bag, then you'll have an ammo/shard tab. If you have profession bags: there will be a tab for those. This functionality replaces two things in Bagnon: Slot coloring and bag hiding. I typically only hid my ammo/shard/keys, and I'm betting that's commonly what other people did as well.

• The buttons right above those are for filtering by quality.

• The buttons on the side are for filtering by item type. The top button is for all items, followed by weapons, armor, quest, consumables, trade goods, and miscellaneous. I could only fit in 6 of the 13 types on the side of the frame, though admittedly a bunch of the types aren't really common, or are covered by other functionality. I'm thinking about allowing the user to configure what of the 13 types to actually show on the frame. The button icons are static, which was one of the requests people had when I was developing vBagnon.

• The text search will function like the text search in Bagnon: typing in "armor" will show armor, typing in "gems" will show gems, etc. Its meant to compensate a bit for not having super fine grained searches around elsewhere.

• I plan on doing some sort of new item highlighting in the inventory frame.

• I'm probably going to list item count totals in tooltips for at least the bag filter tabs.

• Clicking on the player portrait brings up a player selection dropdown. I'm actually viewing Tuller's inventory from another character.

• I've not implemented a display for bags yet. It'll probably be placed in the top portion of the inventory window when shown, and there will be some sort of bag button to toggle the display.

• I've not implemented a list view. That probalby won't happen for a while. I kindof want some functionality they're implementing in 2.3 first.

• I don't have a release date, other than "sometime after 2.2 is released"

Discord

So Lozareth came back, and then left for good. Lozareth was a good developer, and he brought a lot to the community because of the amount of customization allowed by his addons. Without the Discord set of addons, most interfaces would look very bland. I really do hope that some new developers step up to the plate to fill the void (no, it won't be me :P). Trinity Bars, I think, will eventually be the addon that most old Discord Action Bars users will finally settle on. Discord Unit Frames, however, really does not have a valid substitute yet. PitBull might end up being it, but I cannot see how anyone could actually stand navigating through those right click menus for so long to configure anything.

2.2

I'm going to probably work on 2.2 versions of my stuff this weekend. The only two addons I know that need changes are Bongos and Bagnon, and I'm pretty sure the fixes necessary are simple. Technically, Sage probably needs a way of showing who's talking, but I'm mixed about implementing that.

OmniCC will also be getting a GUI, but I do not know if I'll implement it before or after the patch.

Combuctor

I'm getting to the point now where its becoming difficult to really find things in my bank. There's simply too much stuff in it to easily look through. Enter Combuctor.

Combuctor will function a lot like a tabbed Bagnon. Combuctor will clearly separate your normal, profession, key, and ammo/shard slots into a tabbed view. There will also be an easy way to filter based on at least type and name, but I have not decided on a design for it yet. I'm thinking tabs on the side for item type filtering, but I might stick with the same dropdowns I'm using in Ludwig.

I'm also bouncing around between the ideas of simply an iconic view versus an icon + text view. The latter will allow one to determine exactly what an item is by glancing at it, but it will also take up significantly more space. Most likely I'll be sticking with an icon view for space reasons.

I think I may also end up with a list view (Sanity/Possessions) window in addition to the bank and bag windows. Though tooltips can immediately tell you what characters have an item, a list view can make it really simple to figure out who has an item you don't currently have on hand at the time. Ownership tooltips will definitely remain, though I need to make them a bit more efficient.

You may be asking, "Well, why not use Baggins/ArkInventory/EngBags?" They're too complex for me, and I don't think they really solve the problem. Yes, my inventory is grouped, but at the same time, its still typically in one big window. Showing too much stuff at once is the real problem, not organization.

This post is about addon design. Its long, a little old, and probably a bit harsh :)

Thoughts About Design

Code Reuse

• Reuse whenever possible.
• Reuse means less work, thus less bugs, and less code to maintain.
• Higher order functions are good times.
• "Reusing" 100kb of code for a 10kb addon is generally a bad idea.
• "Reusing" 10 lines of code from a 100kb library is also a bad idea, unless you're absolutely certain that library would have been loaded anyway.

Features

• Adding stuff people need is generally a good idea (duh).
• Adding things a single person requires is bad, unless you're sure the general users of your addon will embrace the new feature (or you're that person :))
• If your addon is popular enough, failure to follow rule 2 will eventually result in the creation of a competitor addon to your own.

Interface

• Slash commands are mostly evil. With the advent of load on demand, performance considerations isn't really an argument against them. Your user has a mouse.
• Slash command are great for the following areas: scripting, macros, and commonly used commands.
• The interface for an addon should be obvious to most people. It shouldn't take an hour to say, figure out how to open the options menu. (This doesn't count for people who don't read :))
• Don't give the user too many options at once. Giant menus can freak people out just as much as a long list of slash commands.
• Encourage the user to discover new features.
• Things should work how the user expects them to. Yes, this statment is vague.

Performance

• How well an addon should perform is based on what it should do. Action bars should focus quite heavily on performance, while an option menu shouldn't.
• Features that will significantly degrade the performance of a given addon should be completely separate from that addon, unless rewriting the addon to include those features will not decrease performance.

string.find and string.sub are slow.

• Optimize areas that are executed a lot (duh).

Libraries

• Libraries, even more so than addons, need to have very specific design goals.

Critiques of Other Addons, and Other Stuff

CT Raid

• CT Raid performs poorly. This is a result of poor design (remember when CT Raid and Boss mods were one?), a lack of updates to take into account API additions, and also the decision to retain compatibility with older versions of CT Raid. The only real solution is to rewrite CT Raid, breaking compatibility with older versions like Apple did with OSX.
• They're working on CT Raid 2, as a complete rewrite. This should be good news, as long as its written in a modular fashion. oRA is a good idea, but CT has the network effect to its advantage.

Ace Fallacy

• The usual argument is, "I replaced this group of addons with Ace'd versions, and I gained x memory!" This was NOT due to Ace. Instead, it is due to either the replacement addons being better coded, or the replacement addons having a more narrow set of features (less bloat).
• The best Ace can help with is code reuse, but it comes at the cost of extra overhead.

Ace2

• Ace2 is bloated. An Ace3 (Ac3?) should be written to "trim out the fat", that is reduce the entire thing to just core functionality.
• The greatest strength and weakness of Ace is its community. Pitbull is a very good example of this. It started out as a "lightweight" unit frame addon, and features were rapidly added to it by the community. What has resulted is, however, quite bloated.
• Ideally, Ace2 needs to become a series of downloads with a package management system, like APT. This would result in a system where the user maintains only a minimal set of libraries, with no copies, but also would require a large amount of work. WAU has helped this happen to a certain extent, but the transition is not complete

Dewdrop

• Dewdrop (the method most commonly used by ace addons for configuration interfaces) is evil. It is relied upon not because it is the right tool to use for the job, but simply because its an easy way of creatuing a GUI.
• Simply throwing a bunch of options in a right click menu will not make an addon easy to use.

If you're reading this, you're probably either a user of Bongos or Bagnon, and stalking my profile :)

This will be the place where I'll try and post thing about what I want to do for addon development in the long term. I encourage anyone to post comments (its why I've decided to write things here :))

The first thing I'm going to post here is a long thing I wrote on my old blog thing at wowinterface, entitled Pants. Its just a random collection of things about interface design, some old and some new. It'll probably come off as a bit harsh, but I not mean any harm.