On 08/23/2011 01:05 AM, Dick Hollenbeck wrote: > On 08/23/2011 01:02 AM, Dick Hollenbeck wrote: >> 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. > 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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
