Re: [Kicad-developers] KiCad new look - new icons and new buttons
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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
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. > 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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
On 08/22/2011 02:10 PM, fabrizio wrote: > Dear All, > I have spent some time trying to put together a new set of icons and > buttons that might make KiCad look a little better. > Here you have an example of where I am so far: > http://www.vincentresearch.com/tmp/ > > Would it be possible: > - to know if there is anybody interested in helping me out > - to know if there is anybody willing to help me to modify the current > code in order to accommodate the new icons/buttons. > - to have the .svg files (or some equivalent vectorial format) of the > current buttons set > - > > I do not want to try to undo anything that somebody has done so far > and for this it would be great to have some feedback on the current > status and some opinions on where I am heading. > > I'd like to propose to use PNG format for all icons and buttons and > 64px for the KiCad buttons to start the 6 current programs. Also I'd > like to propose to drop the 16pt buttons used everywhere for a larger > 24px buttons. That includes top bar buttons as well as lateral (left > and right bars). How does it sound? 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 I believe the planning phase of this work is harder than the actual implementation. That is, unless the planning phase is not completed, and the implementation ends up being a conglomeration of afterthought. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
Jerry, thanks for your quick reply. I am glad you can help. I have seen and read about the new icons for OS X. That was my starting point actually. Would you be able/willing to modify the code in order to move to a png format? And most importantly to icon sizes bigger than 16pt? What would be your suggestion in term of size for both KiCad window as well as for toolbar buttons. I have experimented with 26px, see bottom of this page: http://www.vincentresearch.com/tmp/ Eagle however seems to have smaller icons. Inkscape itself (or libreoffice) has quite cool icons, I do not seem to figure out how to download them, any idea? Also, it seems that icons of GEDA pcb are around 22px too. What do you think about it? Do you think there is any problem in moving to .png? cheers Fabrizio On Mon, Aug 22, 2011 at 9:24 PM, Jerry Jacobs wrote: > On Mon Aug 22 21:10:00 2011, fabrizio wrote: >> >> Dear All, >> I have spent some time trying to put together a new set of icons and >> buttons that might make KiCad look a little better. >> Here you have an example of where I am so far: >> http://www.vincentresearch.com/tmp/ >> >> Would it be possible: >> - to know if there is anybody interested in helping me out > > I'm willing to help, i'm very experienced with inkscape. > >> - to know if there is anybody willing to help me to modify the current >> code in order to accommodate the new icons/buttons. > > The only code we need to change is to move it to PNG, because no vectorial > format is supported (as far as I know). > >> - to have the .svg files (or some equivalent vectorial format) of the >> current buttons set >> - >> >> I do not want to try to undo anything that somebody has done so far >> and for this it would be great to have some feedback on the current >> status and some opinions on where I am heading. >> >> I'd like to propose to use PNG format for all icons and buttons and >> 64px for the KiCad buttons to start the 6 current programs. Also I'd >> like to propose to drop the 16pt buttons used everywhere for a larger >> 24px buttons. That includes top bar buttons as well as lateral (left >> and right bars). How does it sound? > > I did put some svg rework in the artwork in the sourcetree of the main > applications. Mainly I did it for use with Mac OS X because 32x32 was way to > small for most purposes. See here: > http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/files/head:/artwork > > Kind regards, > Jerry > >> Best regards >> Fabrizio >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
On 8/22/2011 3:10 PM, fabrizio wrote: > Dear All, > I have spent some time trying to put together a new set of icons and > buttons that might make KiCad look a little better. > Here you have an example of where I am so far: > http://www.vincentresearch.com/tmp/ > > Would it be possible: > - to know if there is anybody interested in helping me out > - to know if there is anybody willing to help me to modify the current > code in order to accommodate the new icons/buttons. > - to have the .svg files (or some equivalent vectorial format) of the > current buttons set > - > > I do not want to try to undo anything that somebody has done so far > and for this it would be great to have some feedback on the current > status and some opinions on where I am heading. > > I'd like to propose to use PNG format for all icons and buttons and > 64px for the KiCad buttons to start the 6 current programs. Also I'd > like to propose to drop the 16pt buttons used everywhere for a larger > 24px buttons. That includes top bar buttons as well as lateral (left > and right bars). How does it sound? > > Best regards > Fabrizio Fabrizio, Your sample images look great! I don't think anyone will object to replacing the existing images with these images. They will give Kicad a much needed face lift. Thank for your contribution to Kicad. I'm looking forward to seeing your images make their way into Kicad. Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad new look - new icons and new buttons
On Mon Aug 22 21:10:00 2011, fabrizio wrote: Dear All, I have spent some time trying to put together a new set of icons and buttons that might make KiCad look a little better. Here you have an example of where I am so far: http://www.vincentresearch.com/tmp/ Would it be possible: - to know if there is anybody interested in helping me out I'm willing to help, i'm very experienced with inkscape. - to know if there is anybody willing to help me to modify the current code in order to accommodate the new icons/buttons. The only code we need to change is to move it to PNG, because no vectorial format is supported (as far as I know). - to have the .svg files (or some equivalent vectorial format) of the current buttons set - I do not want to try to undo anything that somebody has done so far and for this it would be great to have some feedback on the current status and some opinions on where I am heading. I'd like to propose to use PNG format for all icons and buttons and 64px for the KiCad buttons to start the 6 current programs. Also I'd like to propose to drop the 16pt buttons used everywhere for a larger 24px buttons. That includes top bar buttons as well as lateral (left and right bars). How does it sound? I did put some svg rework in the artwork in the sourcetree of the main applications. Mainly I did it for use with Mac OS X because 32x32 was way to small for most purposes. See here: http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/files/head:/artwork Kind regards, Jerry Best regards Fabrizio ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad new look - new icons and new buttons
Dear All, I have spent some time trying to put together a new set of icons and buttons that might make KiCad look a little better. Here you have an example of where I am so far: http://www.vincentresearch.com/tmp/ Would it be possible: - to know if there is anybody interested in helping me out - to know if there is anybody willing to help me to modify the current code in order to accommodate the new icons/buttons. - to have the .svg files (or some equivalent vectorial format) of the current buttons set - I do not want to try to undo anything that somebody has done so far and for this it would be great to have some feedback on the current status and some opinions on where I am heading. I'd like to propose to use PNG format for all icons and buttons and 64px for the KiCad buttons to start the 6 current programs. Also I'd like to propose to drop the 16pt buttons used everywhere for a larger 24px buttons. That includes top bar buttons as well as lateral (left and right bars). How does it sound? Best regards Fabrizio ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
