Re: [Wesnoth-dev] Toward a modular Wesnoth

[Guillaume Melquiond]

On Sat, 12 Feb 2005 23:10:46 +0100, Yann Dirson wrote:
> 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 :)

No, there should be no pokit anymore. Just putting a user campaign in
the development tree and typing "make ..." should work as if it had
been a mainline campaign. My main objective is that there should be no
difference between mainline and user campaigns. Translators of
mainline campaigns don't have to know about pokit; I strongly believe
it shouldn't be any different for translators of user campaigns.

[...]

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

Exactly. I should have made it clear that I was describing the final
package. The development package would contain a "po/" directory with
all the .po files.

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

The merge is purely virtual here. How could you even merge gettext
files since gettext would not know about Wesnoth virtual filesystem?
(for example the get_binary_location function already present in
Wesnoth is purely internal)

[...]

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

The whole point of having a file with a well-defined name (I was
suggesting "index.cfg") is so that it can be easily found and read.

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

Why should we read all the configuration files from a package when we
just want to read one single file called "index.cfg"?

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

There would be one gettext domain by package, but there wouldn't be
the textdomain stack currently implemented in Wesnoth anymore. Maybe
you didn't play the CVS version thursday and friday, but you would
have seen that adding one single textdomain tag to the editor theme
broke almost the entire translation of the game. I don't want to see
such side effects anymore.

[...]

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

Without the dependency stuff, there is absolutely no point in having a
package system. We can continue as we are doing right now, it works
just fine, considering the limited scope of what we can achieve.

[...]

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

The problems? You mean the two I described, music and translations?
Why would it be a problem if the files physically exist? It's no
different from the current situation. There is a problem when the
files don't exist because of their embedding in archives.

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

As much as possible I want to keep around the ability to get istreams
from zipfiles.  So if we switch to a lower level library, it will mean
to reimplement zipios (I don't really mind, but it seems like a
complete loss of time).