http://docs.wxwidgets.org/stable/wx_wxbitmap.html
says PNG format is not supported on Windows version of wxWidgets, but I would
not walk away without consulting the sources.
More below.
PNG can be in the flow of information as an intermediate (man in the middle)
technology. But I would like to treat it as almost a *.o file in a build
process. Our real source file should be the *.svg file. So I would like to see
us find a cross platform tool, and I think you have found that already, which
can be run from the command line to build the *.png files from the *.svg files.
I propose that we agree never to post edit the PNG files, and that they must
come from the *.SVG files. I suggest we have a separate CMakeLists.txt file to
build the *.PNG files from the *.SVG files automatically, but perhaps not make
it a mandatory part of the build process, on the theory that some builders will
not want to have the tool which converts from *.SVG to *.PNG installed.
*.SVG -> *.PNG
Therefore this means distributing both the *.PNG and the *.SVG files as part of
the source tree. That is, unless you want to burden every builder with the need
to have this tool installed.
Then we have to decide on how to load the PNG files into the programs, and there
seem to be at least two ways to do this:
A) read the *.PNG files into memory from disk at program start time.
B) convert the *.PNG files into a BYTE array which is compiled into the
respective program. But the byte array is definitely a PNG format, meaning we
get the advantage of the alpha channel support, which we do not currently have.
If B) is the chosen path. This entails yet another step that we need to add to
the build path, meaning it needs to go into a CMakeLists.txt file and needs to
be able to happen from a commandline tool.
*.PNG -> *.cpp
http://www.libpng.org/pub/png/book/chapter09.html
Although we are going with larger ICONs, I believe there may be no real memory
penalty since the PNG byte array is essentially be the PNG file in RAM, and it
is in a compressed format already.
So I think sticking with a BYTE array is the best path, because it will lead to
faster loading and we can continue to maintain the bitmap collection as a
library, and applications can continue to link against that. I'm just proposing
that we put some of the build paths into a well documented CMakeLists.txt file,
one that does not necessarily run all the time as part of the normal compilation
process.
