← Back to team overview

kicad-developers team mailing list archive

Re: KiCad new look - new icons and new buttons


On Tue Aug 23 08:14:26 2011, Dick Hollenbeck wrote:
On 08/23/2011 01:05 AM, Dick Hollenbeck wrote:
On 08/23/2011 01:02 AM, Dick Hollenbeck wrote:

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

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
And if you are really paying attention, you recognize that the "byte array
containing" *.cpp files for the bitmaps would also need to be distributed as
part of the source tree also.

A reasonable tool to convert the *.PNG files into *.CPP is a cmake script itself.

In doing so, it can also write code to generate a global wxBitmap from the
filename of the PNG file.

The cmake script can be chain loaded from a CMakeLists.txt file which builds the
bitmap library.

So I rescind my proposition that the *.cpp files must be distributed as part of
the source tree.  They can be generated by a *.cmake script.

I totaly agree with building the png's by CMake out of the svg's. It saves alot of pain in the end. Maybe a better approach is that the png's are shipped with kicad as resources and load at runtime.

Maybe we should have a look at the wxwidgets examples and http://zetcode.com/tutorials/wxwidgetstutorial/menustoolbars which uses the wxBitmap with PNG.

Kind regards,