From cargBags to Bagrealis

Over the last few months I was heavily thinking on how to improve cargBags, my inventory addon for WoW. The plan was to rewrite the whole core for version 2.0 to improve its overall performance. But let’s take a quick look into the history of cargBags, before coming to the list of things that did not work out as expected.

cargBags was released with version 0.3 as a simple and lightweight inventory framework inspired by oUF. It should only have the most important features for updating buttons and the rest should be made by layout and plugins. From day one, cargBags was my major addon and basically teached me most of my Lua knowledge. For every major rewrite, I concentrated on the new problems of the previous version and with them in mind, I completely redesigned the core. In Version 0.4 (the first rewrite), this was the Handler-system, which should allow other data sources than the Blizzard API, e.g. viewing the bank from everywhere. Version 1.0 was an even more complete rewrite, featuring the filter-system which gave rise to the first layouts of other people. Now items could be categorized into different bags by different filters instead of only bagID. The new problems with the filtering system and the increase in feature requests gave me the need to work out another rewrite. In detail:

• Diversity: From beginning on, my goal with cargBags was to make all current bag addons reproducable with the cargBags-framework, going from All-In-One-designs to lots of categorized bag frames such as Baggins or ArkInventory or presenting tab-displays and filter-buttons. I even tried to make list-based inventory frames possible. The whole flexibility needed a lot of API functions, variables, options to function for all these different types of layouts. While I believe that I managed it fairly good, it has now come to its limits. Especially the _Nivaya-layout tried to work around my API limitations to include new features – Sorting as the most difficult example. The open API of cargBags became more of a prison than a good help for some layouts and they would maybe be better of without a core which blocks new features.
• Lightweightness: At the beginning of cargBags, I was fairly naive concerning the term ‘lightweight’. For most people, this term is defined simple: Lua-only config, small memory footprint. And this was the direction in which cargBags was headed from start on. But with all the new feature-requests, I learned an important thing: The more you try to keep memory usage down, the higher the CPU usage gets. cargBags is still leading if you look at feature-richness per memory usage, but it is nowhere near being lightweight. Reducing CPU-usage is the key to this goal, but this means to increase memory usage and re-educate the users of cargBags. And then they could just use another bag addon. To prove that cargBags is not lightweight enough for the users anymore, you just have to look at the emergence of other lightweight-bag-addons like ncBags or Stuffing.
• Community Support: While I really appreciate all the feedback and bug reports and the success of cargBags was more than I dreamed of, it was lacking one thing: support of developers. There are only two released layouts from other authors and a few modified original ones locked down in UI compilations, but no plugins and no handlers. oUF, for example, really lives through its active developer community. You know that if you want to have a feature implemented, you write it by yourself. But in cargBags, it often relied on my side (or on the side of the other authors) to implement new features. A few people tried to modify their layouts and also provided feedback and tutorials (again, thanks for this!), but the overall response was not enough to let cargBags grow by itself. And this is what is needed for this ambitious goal that a open-API framework has: Growth by community.
• It does not ‘feel right’ anymore: In the recent time, I was really overchallenged by all the new problems and feature-requests to which I could not find a solution without violating the core principles of cargBags. The CPU-usage is too high and in addition some people requested a simple ‘back to the roots’-version of cargBags without all the filtering-stuff. Nevertheless, new users requested to have improved anywhere-support, better filtering and more possibilities. It marked the beginning need to divide cargBags into two separate addons – but that’s not how things work for me. I only work on things in my freetime I personally need, because otherwise I quickly lose interest. I would never use both versions of cargBags, so one version would get a raw deal and would not improve much. In addition I’m not satisfied with cargBags anymore. Everytime I look at it, I see the problems which I need to fix for the community – problems I would never come across with my personal use.

The solution to all this is simple: Start anew and rewrite cargBags from ground-up, another time. And this is what I’m doing since a few months ago, developing a new, hopefully better inventory addon which solves all the mentioned problems. But this won’t be an addon which deserves the name ‘cargBags’. I’ve realized that the focus on small memory-consumption and the open API was wrong and I try to take another direction. My alpha-quality addon ‘Bagrealis’ is a completely new approach to the inventory frame, this time without any open layout API, so I can get it more optimized. And the way it works without filters should really reduce CPU usage. You can find out more about it from my previous posts, here and here.