[Interface] [Engine] Improved Add-on Management System

[gudo]

The current add on management system is sub par, especially when compared to other open source projects. The main problems with Wesnoth's system, in no particular order
1: When downloading new content, it is impossible to tell which content is already downloaded
2: Add-ons must be selected on at a time
3: A few add-ons have dependencies (i.e. a campaign requires a user to have a certain era downloaded as well). The current system neither indicates this nor automatically downloads the dependencies.
4: [Trivial] You can not remove add-ons from the same screen you can un-install them from.

Clearly, there is room for improvement, especially considering the future direction of Wesnoth development. According to the Developement Roadmap, versions 2.x and on are to be modular in nature. Highly modularized projects demand a sophisticated package management system.

The improved add-on management system should:
1: Centralize and list all currently installed Mainline and 3rd party modules
2: Have a one or two click "update all" feature. This would essentially turn the add-on management system into an automatic update system. (Note: This should only update the game to major/stable versions. Advanced users will still be able to get nightly/experimental builds through other channels. This is intended to be for the convenience of non-technical users)
3: Be able to update just selected modules.
4: Be able to install new add-ons. (Multiple at the same time.)
5: Be able to uninstall add-ons.
6: Be able to update itself.

The open source project OpenTTD has a package management system that does nearly everything I listed above. As their architecture isn't fully modularized, it is impossible to update the core game files or the package management system. I propose that Wesnoth implement a similar system. In fact, both the license for Wesnoth and OpenTDD are flavors of GNU GPL. It may be possible to copy and adapt large portions of OpenTTD's code.

Not only will such an improved add-on management system improve the user experience, it will also move the project on to a firm platform for development of the 2.x series. This could make an excellent Summer of Code project.

[StDrake]

what is your understanding of the difference between removing addons and uninstalling them? installation and uninstallation of wesnoth addons is not like in Windows - it's simply copying and removing the addon files from where the game reads them
about the features you mentionned:
1. mainline modules come with the installation package
2. HABD
3. HABD though it seems you can only update either one at a time or all of them without exceptions
5. HABD
6. the addon management system should be able to update itself or the whole game?

what version are you using that you missed the "update addons" and "remove addons" buttons?

one thing I can for certain agree with - the addon download list should somehow note which ones are already present on the client station

[beetlenaut]

Clearly, there is room for improvement

It's not that anyone will disagree, but some volunteer has to get around to making it. You are not bringing up anything that hasn't been brought up many times in the past:
http://forums.wesnoth.org/viewtopic.php?f=12&t=18328
http://forums.wesnoth.org/viewtopic.php?f=12&t=24469
http://forums.wesnoth.org/viewtopic.php?f=12&t=24730
http://forums.wesnoth.org/viewtopic.php?f=12&t=32159
http://forums.wesnoth.org/viewtopic.php?f=12&t=25816

[gudo]

what is your understanding of the difference between removing addons and uninstalling them? installation and uninstallation of wesnoth addons is not like in Windows - it's simply copying and removing the addon files from where the game reads them

I believe the current process to be slightly more complicated than that. There is a state file of some sort somewhere that does list what addons have been installed and what version they are. The hard parts of creating and editing this file have already been taken care of, it just needs to be utilized for more.

1. mainline modules come with the installation package

Currently, if just one mainline module gets updated, the entire installation package must be updated by the dev team, and downloaded and reinstalled by the (average) end user. (I do realize that some of the more advanced users will be able to simply find and apply the diffs.) This is a waste of everyone's time, and the project's bandwidth. As the project becomes more and more modularized for the 2.x series, the current distribution model will make even less sense.

There are other advantages to allowing the addon manager to update mainline files. For example, we could pull the mainline modules out of the installation packages and have them be fetched through the addon manager. This would drastically shrink the size of the installers, and make it so that there would only need to be one install packager per platform instead of one per platform per version. Keep in mind that the current distribution model has two versions per platform, stable and development.

2. HABD
3. HABD though it seems you can only update either one at a time or all of them without exceptions
5. HABD
6. the addon management system should be able to update itself or the whole game?
what version are you using that you missed the "update addons" and "remove addons" buttons?

I'm sorry, I'm afraid I'm unfamiliar with the meaning of HABD. Google turns up "Helicopter Aircrew Breathing Device" and "Hot Axle Box Detector," neither of which are what you meant, I'm sure. I do know that these are features that are implemented in the current system. You'll notice that I've not included them in the list of problems with the current system. I've listed them as things the improved system should be able to do (preferably all from the same screen.)

[beetlenaut]

HABD = Has Already Been Done.

[pauxlo]

Clearly, there is room for improvement, especially considering the future direction of Wesnoth development. According to the Developement Roadmap, versions 2.x and on are to be modular in nature. Highly modularized projects demand a sophisticated package management system.

Not to disagree here, but I doubt the "development roadmap" still has much relevance. The file was last touched in 2008, and the base text there is still from 2005. You may ask in the IRC channel how many of the current developers even know this document exists.

[salade]

Not to disagree here, but I doubt the "development roadmap" still has much relevance. The file was last touched in 2008, and the base text there is still from 2005. You may ask in the IRC channel how many of the current developers even know this document exists.

As a supplement to your point, if the "development roadmap" is no longer valid, it should be marked as obsoleted.

[Gambit]

If I recall correctly, a new add-on interface is already in the works for 1.10.

[Iris]

Ilor was mostly working on a new server application, and that branch has not received updates in a long time since he’s also currently missing.