Re: [Wesnoth-dev] Toward a modular Wesnoth

[Yann Dirson]

On Sun, Feb 13, 2005 at 01:25:31AM +0100, Guillaume Melquiond wrote:
> 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.

The pokit is only some sort of (easily update-able) template for
i18n'd campaigns.  As such, I think it (or some derivative of it) will
still have a place here.  Translators do not need to care about it if
the campaign already contains the necessary files, whether official or
3rd party - it's just that official campaign have by nature the
necessary support.

Having exactly no difference between official and external campaigns
would be problematic.  Official campaigns have their Makefile
generated by configure, and indeed, initial revisions of the pokit
worked that way, precisely to make the differences as small as
possible - but I changed this because of the unnecessary bloat.  And
I'm not sure it would be good to use the current pokit in the official
campaigns, but we could check.


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

Sure, but the zipios API is not really designed for such a use.  I'm
not sure, but there may be a pretty high overhead for doing that
(openning a zip, reading a file, closing it).


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

I did not mention reading all zip'd files, only scanning the zip's to
find the index.cfg.

If we go that way, it would be something like adding an implicit
package=httt.zip instead of the #ifdef'd {indlude}s we currently have.
We could get rid of the #ifdefs in a similar way without the notion of
a package - not that I'm opposed to packages, but we could go forward
in an incremental fashion, since your proposal as a whole looks pretty
disruptive to me.


> 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 understand this concern, but I'm not aware of that problem you
mentionned.  I shall look at it.


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

No, packages without dependencies would still help to package official
packages independently.


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

Right.

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

No, it's a problem because of the Zipios::Collection design.  Whether
you use a DirectoryCollection or a ZipFile, you can only get an
iostream to the individual files, not a path.  That would break the
notion of transparent access.


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

So would seem the idea of reimplementing the Zipios::Collection
mechanism in a way that would allow to access plain files for the sake
of storing music and messages in a non-zipped package.

So by lack of other choices, I'd elect "enhance SDL and libintl to
support sdl_rwops" winner of the contest :)

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