Re: [Wesnoth-dev] Toward a modular Wesnoth

[Yann Dirson]

On Sat, Feb 12, 2005 at 07:12:08PM +0100, Guillaume Melquiond wrote:
> 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.

This looks like a good goal.  However, translating user campaigns is
not reduced to adding 2 tags in each scenario - that will not be
enough to significantly reduce the README.pokit length :)


> At the moment, the "data/" directory is a mess; and there are
> "images/", "sounds/", "music/", "translations/" (named "po/" during
> development, renamed during installation) directories.

Sidenote: po/ and translations/ do not have the same structure.  Using
the standard gettext Makefile requires us to group the catalogs by
textdomain in the source tree, but libintl expects compiled catalogs
to be grouped by language and use different names.

> 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).

We may still have to keep po/ as a source for packages/translations.

> All these sub-directories (except for "translations/") would be
> merged

translations/ could be merged as well, since the catalog files are
named by textdomain, and should not overlap.

>: 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.

This type of abstraction is supported by zipios, for both directories
and zip files.  We could get rid of the old path-searching system and
turn zipios into a requirement.

> That way, there would be no need
> for "binary_path", "address@hidden", and campaign-ifdefing anymore.

About campaign-ifdefing - that reminds me from an objection to your
previous mail, which I had forgot to express.  Currently, campaigns
are declared to wesnoth by putting a wml file in campaigns/.  If we
want standalone per-campaign packages, we surely do not want to
separate campaigns/httt.cfg from packages/httt.zip - imho this would
contradict the very notion of a package.

But if we put those campaign-definition files into the package, that
will require to scan all packages for those campaign definitions.
This is somewhat similar to what's currently done, and I don't see how
you can get easily rid of the ifdef here - can you give more details
about what you're thinking about here ?


> 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.

I guess you mean getting rid of the textdomain tag only, not the whole
concept, right ?  I'd see what you describe as infering the textdomain
from the package name.


> I don't think it would be that hard to implement.

At least the coding part of turning all our campaigns to use such a
consistent pakage layout would be quite easy to do in the current
state of things.  As far as revision history is concerned, that would
be a problem because of CVS: as always, we "lose the link" when we
move a file.  You'll have guessed I'm about to reiterate my suggestion
of switching to subversion :)

I'm less sure about the package dependency stuff, but the fact I don't
grasp yet how you intend this to work can be blamed here :)


> 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).

Hm, it is a matter of the missing function being implemented in SDL.
We could send them a patch :)

> 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.

We could get in touch with Bruno Haible to see whether he'd be willing
to add to libintl a mechanism in the spirit of sdl_rwops ?


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

If we use zipios collections as the underlying mechanism to merge the
package contents, then we have the problems even with plain dirs.

If otoh we switch to using/implementing another mechanism, then we
should better throw zipios away, and look at lower-level
zip-accesssing libs.

Regards,
-- 
Yann Dirson    <address@hidden> |
Debian-related: <address@hidden> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>