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. 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. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
