kicad-developers team mailing list archive
Mailing list archive
Re: KiCad new look - new icons and new buttons
Dick Hollenbeck <dick@xxxxxxxxxxx>
Tue, 23 Aug 2011 00:39:19 -0500
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20110617 Thunderbird/3.1.11
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:
> 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.