(Slightly edited resend, the original got spam-binned by gna.org.)
I'm writing to propose some changes and a slight tightening of the WML
rules for resolving image references in 1.3. Right now would be as
good a time to do this as any; we've just broken backward
compatibility with the new terrain system, after all, and the
additional burden on people updating UMC would not be large.
My original motivation for this proposal was making macroscope work.
I have since worked most of the way around these misfeatures, which
is how I've been able to cut the list of broken image references
dramatically down to size (from over 90 to about 34). But they remain
misfeatures and should be fixed, and one of them is still a serious
functional problem for macroscope.
The problem has three aspects:
(1) The rules for resolving a path in an image attribute vary
in tricky ways depending on the enclosing tag and a concept of
'binary path' that I'm not sure I understand completely.
(2) These resolution rules are not actually documented anywhere I can
find -- and two senior devs have not been able to point me at a
clear explanation in the docs, either.
(3) Under some circumstances, it is permissible to leave off the .png
or .jpg extension on an image argument.
Problems (1) and (2) require macroscope to jump through elaborate hoops
to tie an image reference back to its corresponding resource file.
Problem 3 means that in some cases macroscope cannot even recognize
that an image is being referred to -- for example, when it is the
argument of a macro call.
Making macroscope work better would be worthwhile -- the tool has
already demonstrated its usefulness. I was able to use it to clean
out about a half dozen bits of cruft and historical tag-ends in the
macros and to fix around 70 instances of bad references to
nonexistent sound resources and image (look in the svn logs for "Found
by macroscope"). In the future, macroscope promises to be a reliable way to
detect reference typos and other mistakes like using ".wav" where
".ogg" was intended or vice-versa.
However, I also feel that -- independently of macroscope -- the
murkiness of the current rules is a bug that is probably confusing to
WML authors and is certainly going to hinder extension of WML down the
road. The workaround would be to document them well; the real fix
would be to simplify them.
Here is what I was told about the current rules on IRC:
<esr> My problem is that image= declarations sometimes give
path relative to images/ and sometimes just give a
basename -- I need to know what resolution rules WML
uses in the second case.
<zookeeper> image= stuff is looked in images/. sounds are looked
in sounds/. a [binary_path] adds a dir as a new base
dir (base dir being the dir that contains the images/,
sounds/ etc dirs)
<zookeeper> give an example of a place where "just a basename" is given?
<esr> Zookeeper, here's one: tutorial/units/Fighteress.cfg:7
<zookeeper> esr, ok, that refers to Tutorial/images/units/images
<zookeeper> i think unit images are also automatically looked in
images/units/ and terrain images in images/terrain/
<zookeeper> esr, i don't think there are similar minor special
cases elsewhere. i think.
Alas, Zookeeper was wrong about that. There are, as it turns out,
other minor special cases near portraits and items.
<Torangan> They're searched in every binary path declared...
<zookeeper> the only things in terrain graphics WML and images that are
special (IIRC) are the fact that image names don't have that
.png in the end (which is sort of dumb...) and the
directional variants, like [EMAIL PROTECTED]@R1, which
probably aren't resolvable by your tool, but then
again i don't think that's very useful either
The thing I most want abolished is the option to have the WML
autocomplete the file extension. Or, to put it another way,
macroscope needs all image file references to be detectable in a
context-independent way with a regular-expression match, rather than
by requiring a WML-aware parse of the file. The easiest way to do
this is to require that all references have one of a small set
of recognizable suffixes like ".png", ".wav", ".ogg", and ".jpg".
Adding to that set of extensions is not a big deal, but the set
has to exist for any tool like macroscope to have a prayer of working.
Second, the special path-search hacks dependent on enclosing tag
should go away. The fact that even *Zookeeper* (who the other devs
seem to regard as a god of WML) wasn't sure where all the edge cases
were -- and turned out to have gotten them wrong -- tells me that this
design is overcomplicated and broken.
Third, the remaining rules should be clearly and unambiguously
documented in a page that is linked from every discussion of
image attributes.
In both the misfeatures I just called out, a shortsighted notion of
"convenience" has damaged the simplicity and transparency of WML.
Let's fix that now, early in the 1.3 branch while it's still easy.
In case it is not obvious, I am willing to do the tedious job of
upgrading the mainline WML so that it no longer relies on these
misfeatures. Doing so would be a natural way to debug macroscope,
in the same way that finding those unresolved sound references was.
I'm also willing to write the documentation once we settle on
the new rules.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
The price of liberty is, always has been, and always will be blood. The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty. Are
you free? -- Andrew Ford
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
