kicad-developers team mailing list archive
Mailing list archive
Re: KiCad new look - new icons and new buttons
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.
> 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.