[Wesnoth-dev] Toward a modular Wesnoth

[Guillaume Melquiond]

Hi,

I already sent a mail about my thoughts on packaging a modular
Wesnoth. But I recently had to go through some part of the code base
when trying to fix some bugs with zipios and user campaigns, and when
trying to figure the recent "textdomain" failure. So I now have a more
precise idea on what could be achieved; I'm posting it here, because I
won't have time to work on it it right now, and later a 1.0 release
may preclude it.

One of the goals is to remove all the "textdomain", "binary_path",
"address@hidden" stuffs, so as to simplify the design of
campaigns/multiplayer/etc. There wouldn't be any difference between
user and mainline campaigns: a mainline campaign could be moved to the
user directory and would still work, and reciprocally. And they would
have the same translation mechanisms, no need to go to great length
anymore to translate a user campaign.

Another goal is to clean the WML cache handling of Wesnoth. For
example, when looking at my cache directory, I see a file labeled
"CAMPAIGN_THE_DARK_HORDES-EASY-MULTIPLAYER-lang_default". What?!
Wesnoth does support multiplayer campaigns and it wasn't even written
in the Changelog?! More seriously, there is also the whole
campaign-ifdefing idea that I find quite disturbing. It would be a lot
better if we hadn't to use it, by design.

At the moment, the "data/" directory is a mess; and there are
"images/", "sounds/", "music/", "translations/" (named "po/" during
development, renamed during installation) directories. So, here is my
proposal: remove all these directories. And replace them by a unified
model. One single "packages/" directory, located at two places to
provide per-system and per-user storage (as is the "data/" directory
at the moment).

This directory would only contain other directories, or zipfiles
containing a compressed directory. Each of these directories/zipfiles
would contain an "index.cfg" file describing the package and its
dependencies (see my previous mail if you don't understand what I mean
by dependencies). It would also contain "data/", "images/", "sounds/",
"music/", "translations/", etc. sub-directories.

All these sub-directories (except for "translations/") would be
merged: all the "images/" directories of the opened package tree would
be seen as a single directory "image/"; kind of an union mount point
for those familiar with this BSDism. That way, there would be no need
for "binary_path", "address@hidden", and campaign-ifdefing anymore. As for
translating a package, the strings would be taken from the
"translations/" subdirectory during WML parsing. No need for
"textdomain" anymore, and it would be as easy to have a translated
user campaign than a mainline user campaign.

As for the cache, the file would be named after the top-level package
that opened all the needed others. In a sense, it wouldn't be that
much different from the current scheme where the cache file is named
after the campaign name. The name would still contain all the defined
macros (except for campaign-ifdefing that wouldn't exist anymore), in
particular the difficulty setting.

I don't think it would be that hard to implement. But there are some
details that wouldn't work. For example, musics can't be stored in
zipfiles at the moment, but I wouldn't be surprised if it was only a
matter of time (it is the remaining part of the SDL not yet
converted). More annoying, .mo files can't be stored in zipfiles, they
would have to be decompressed, or we would have to ship our own
enhanced intl library.

But other than these two problems (that don't happen when using plain
directories), such a mechanism would work just fine in my opinion. Any
thoughts on this?

Regards,

Guillaume