kicad-developers team mailing list archive
Mailing list archive
Re: KiCad new look - new icons and new buttons
says PNG format is not supported on Windows version of wxWidgets, but I would
not walk away without consulting the sources.
> 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
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
Then we simply have to do some global PNG setup before using the wxBitmap
constructors, etc. Perhaps instead of putting simply the byte arrays into the
library, we can also put named global wxBitmaps which are instantiated one per
bitmap library source file. This way we hide in the library, some of the
details of the bitmap construction also. It looks like this is possible, that
we can construct a wxBitmap well in advance of any window it is to be used in.
We have to visit the wxWidgets sources to see if we can trick the windows build
of it, into using PNG format. It it likely a behind the scenes library is
needed, and that that library normally is not build or present on windows. It
is late now, otherwise I'd continue with the research.