Back in January, I posted my initial plans for Wesnoth 1.12 in the developers’ mailing list to gather some feedback and hopefully motivate other developers to do the same with theirs. Guess what, that didn’t work, so here I am back at home cooking up code and user interface changes in solitude. In fact, it’s all almost ready for 1.11.0.
1.11.0 is getting closer, but it’s still a little too far; this is mainly because the map format and editor changes in trunk have not been finalized yet and loose ends abound. Thankfully, I am not the one responsible for that mess. My mess is much prettier, practical, and necessary; and it is this mess that my post is all about.
Anyone who has used add-ons in Wesnoth 1.8 and 1.10 should be able to recognize this window; previously called the “Get Add-ons” dialog, now called the “Add-ons Manager”. It remained largely unchanged during 1.9.x because I spent two years dealing with more pressing matters, so the differences seen in this screenshot should be quite obvious. But this didn’t come to be possible in a couple of days, no; in order to enable these improvements to happen I had to refactor an amount of ugly and inefficient code I had previously moved around during 1.5.x, and then add a few back-end features here and there. That button on the top right corner? Rocket science, I tell you.
Most of my mainline commits since March have revolved around this area, starting with the refactoring that allowed me to implement the basics for actual add-on status tracking in the engine; that is, now it’s much easier to tell whether an add-on is installed, upgradable, or outdated on the server, without duplicating massive amounts of code. There is also a degree of separation between the add-ons manager UI layer and the client-server interaction code that might allow even better features to crop up in the future, such as upgrading add-ons from the MP lobby when deemed convenient by the user and/or the game.
But for now, I’ll focus on the add-ons management UI goodness that has already landed in trunk over the last couple of months.
Perhaps the most obvious change at first glance is that add-on list rows come with a status line indicating whether a particular entry is installed or not, amongst other things. For those skimming the add-ons server list, the color formatting should aid in quickly identifying entries of interest.
A less obvious change is that add-ons are not initially sorted by upload time anymore. This makes the age-old tradition of rushing uploads to a newly started server absolutely irrelevant from now on, since add-ons will be first sorted by title instead. Incidentally, for this purpose I was originally going to use identifiers (directory names), but then I found out there are quite a lot of people who upload add-ons with mismatched ids and titles.
Now we can also filter the add-ons list according to the kind of content we are looking for, in addition to the previous keywords-based mechanism. The additional options allow for displaying only add-ons with a specific installation status and belonging to specific categories. I am sure I don’t need to remind add-on authors about doing this properly since the basics of add-on classification have been around since 1.5.1 (mid-2008).
Installed add-ons are displayed with additional information when applicable, such as whether they can be upgraded or not, and what the installed version is relative to the version on the add-ons server.
The Upgradable add-ons view behaves identically to the old Update Add-ons dialog, which has been merged into the main Add-ons Manager in order to reduce code duplication.
The Description button still allows for displaying more information about the currently selected add-on, including its description and available translations. Don’t mind the gap at the start of the description in the screenshot, though; that’s the maintainer’s own doing.
Finally, we get a nice warning if we attempt to install add-ons from the server which we have already installed and contain .pbl files or version control (e.g. Subversion, Git) metadata. This is only relevant for add-on authors, maintainers, and contributors who might accidentally lose their changes otherwise.
Not pictured in any of these screenshots is the addition of a whole new Help section dedicated to explaining the various add-on types, how they are played, and how they are managed. You can see the accompanying Help button in the Add-ons Manager dialog, though.
All this shouldn’t be news for those who regularly follow me on IRC (either #wesnoth-dev or my personal channel on freenode) or Twitter, although I may have neglected the latter crowd in order to make this proper post sound a little more impressive. Frankly, I can’t accurately describe how awesome these improvements are by myself; thus, I encourage people to try them out when they get a chance, either by building and testing current trunk—with all the implications—or eagerly awaiting the upcoming 1.11.0 release, and the beginning of this long road to 1.12