[PATCH 02/48] Added new icon build rule

Joel Holdsworth joel at airwebreathe.org.uk
Mon Mar 22 08:10:03 CDT 2010


 

> I still think that having to commit 10 source files per icon is not
> acceptable, even with subdirectories.
I agree it is a lot of source files, but I don't see that that's a problem if
they're stored neatly within a resources subdirectory. user32.dll has a lot of
images, but that's not a problem for this reason. In fact by creating resources
subdirectories surely I'm tidying? because it unclutters the mix of resources
and source code in many dlls.

The issue is that the 9 images are never going to go away - a full XP icon has
at least 9 independant hand crafted images to go into it. Vista and 7 icons have
even more.

Now the question is what to do about it?

The two approaches I can see are to keep them independant and stored neatly, or
to package them somehow.

Keeping them independant is ideal from the artist's point of view because the
SVGs and PNGs can be viewed and editied in their native format.

I could package them together into an archive of some sort e.g. an icon.tar.gz
file. That would make the build rules easier, but it would mean the individual
images could not be individually versioned, and make them slightly harder to
edit.

An alternative we discused was to use a .ico rather than a .tar.gz as an image
repository. However this has several problems:

1. Ugly blurring of the line between source binary and compiled binary: The
build rule becomes 1x.ico + 4x.svg -> .ico. Kinda circular.

2. .ico files are a real pain to work with from the artist's point of view. It's
a very unusual image format.

3. It's so easy to screw up the icon's internal structure, or change the format
of a sub-image without meaning to. Many image editor apps will not generate a
byte for byte identical file in an open->edit->save process, and many image
editors would subdly change the ico format, and git version history would not
make that kind of change clear.

4. Even then you're still left with 4 images - 1x .ico and 3x .svg, so the
problem is still pretty bad.

I favour the individual images approach, or I could do a package approach if you
like, but I can't see how a .ico package could work. Do you see my problem?

Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100322/0cd79356/attachment.htm>


More information about the wine-devel mailing list